Where are the edges and best practices for Teams, Customers, and Organizations?
Asked by Dom:

I'm trying to unravel this layer cake of confusion, and I assume I'm not he first one to run into it.

I'm using Assets, so I also have Customer Assets that link to user accounts in the Atlassian Account directory.

We use Work Management Projects, Confluence, and a Service Desk currently. All company-managed.

I need to understand which Teams, Customers, Organizations, and User constructs I need to manage and care about, in which contexts, and all of their documentation are written as if they are the only thing with that name in existence.

There are at least four distinct "Team" constructs right now, depending on whether you've been "updated" recently, and a bunch of essentially duplicative yet separate Customers / Organizations / Users constructs that are sometimes integrated, sometimes not, and nothing global.

What is required and what can be cut? All of these constructs have no mature administrative management options either - everything is "add users one at a time by their email address!" like I want to sign up to do that for hundreds of accounts over five of these poorly thought-out and terribly integrated features. :(

Can anyone make sense of this morass? Is there a guide I'm missing that sets up the options side-by-side and gives some sense of which you need and which work together for different use cases or something?

Help!


Answers:
author: Eugenio Onofre
body: Hi [@Dom](/t5/user/viewprofilepage/user-id/423404)

**Customers:** Customers are people who request help from your service project. Learn how you can add and remove them from your service project.  
<https://support.atlassian.com/jira-service-management-cloud/docs/add-and-remove-customers/>  

**Organizations:** Organizations are groups of customers that can be used in multiple service projects. When you add an organization to a project, its members can raise requests in the project and share them with the organization. They're also notified about the organization's requests and can view and search them on the requests list in the help center. This also means that the request will be shared with all the organizations members when the organization is added to the request.  
<https://support.atlassian.com/jira-service-management-cloud/docs/group-customers-into-organizations/>

**Teams:** An Atlassian team is a collection of users that are part of your real-world team. Your team has members, a team profile, work, and team resources.  
<https://support.atlassian.com/atlassian-account/docs/what-is-an-atlassian-team/>

**Users:**A user is any individual who can log into your Jira instance and counts towards your Jira license. A group refers to a collection of users who share the same global permissions. Using groups is an easy, convenient way of managing a collection of users when multiple users in your organization need the same permissions or restrictions.

Please remember to accept this answer in case it helps you resolve your question as it may also help other community members in the future.

Regards,  
Eugenio

comments: author: Dom
body: Eugenio,

That is as far as I got with the documentation as well, but thank you for the concise summary.

Starting at this point, here's some of my real questions:

An **Atlassian team** does not equal the **Opsgenie team(s).**

To put another way, **Invite team** on the left side bar in a Service Management is tied to the Opsgenie flavor, which is required for on-call and all kinds of reporting / automations.

The Teams at the top of the page, Atlassian Teams, are completely different elements with completely independent management.

The **Opsgenie Teams** require membership to be managed in the Opsgenie screens, with nothing but single-user entry options.

These are related to the **Services**, from that Assets locked element.

**Opsgenie Teams** do not connect to **Atlassian Teams,** nor to the **Assets** service as a whole where I could connect them to the **Users** schema.

Teams historically have been designated by custom user group for our environment.

In order to ensure a "Team" of people is consistent, I have to manually manage an Opsgenie Team, an Atlassian Team, a custom Group, the User Directory entries, and an Asset Schema?

And most of that with no option at all but use a UI which has almost no bulk, filtering , or change management features?

Am I missing something there?

I'll stop here for now - figure just adding more questions would get confusing.


Tags: assets

cloud

company-managed-projects

jira-cloud

jira-service-management

jira-service-management-cloud

jira-work-management-cloud

opsgenie