Configuring a Matrix Organization in Crowd

[Caroline Kerrigan]

Has anyone had to configure groups/organizations for a matrix-style organization in Crowd? What processes do you use to vet new user requests to ensure the resources users get access to are being used for the correct purpose? 

We have a mix of internal and external users using Jira, JSD, Confluence, and Bitbucket. 

I would appreciate any documentation with similar use cases.

Thank you! 

[LynnG]

've seen a few organizations handle this successfully by treating Crowd as an identity and group management layer, while defining access around business roles rather than application permissions directly.

Common approach for matrix organizations

Instead of creating groups like:

• confluence-users
• jira-users
• bitbucket-users

create business-oriented groups such as:

• finance-team
• product-managers
• contractors
• customer-a-project
• vendor-x-support

Then map those groups to application access and permissions within Jira, Confluence, Bitbucket, and JSM.

This makes it much easier to answer:

Why does this user have access?

because access is tied to a business role or relationship, not a technical group.

---

Internal vs External Users

Many organizations keep these separated at the identity level.

Example:

employees
employees-engineering
employees-product

external-users
customer-a-users
vendor-x-users
consultants

This allows for:

• Different onboarding workflows
• Different approval requirements
• Easier auditing
• Faster offboarding

A user can then belong to both a business group and a user-type group.

---

Request and Approval Process

A common governance model is:

1. User requests access.
2. Request specifies:
   • Business justification
   • Project/customer
   • Required applications
   • Duration (especially for externals)
3. Resource owner approves.
4. Crowd administrator (or automated process) assigns groups.
5. Access is reviewed periodically.

For external users, many organizations require:

• Sponsoring employee
• Expiration date
• Periodic access recertification

---

Access Reviews

The biggest challenge in matrix organizations is access sprawl.

A practical process is:

• Quarterly review of external users
• Review users with admin rights
• Review users in project/customer-specific groups
• Remove inactive accounts
• Verify sponsor still exists for contractors

---

Example Group Structure

Plain Text

1

employees

2

external-users

3

4

jira-software-users

5

confluence-users

6

bitbucket-users

7

8

project-alpha-users

9

project-alpha-admins

10

11

customer-acme-users

12

customer-acme-confluence

13

customer-acme-jsm

Show more lines

Users receive access through combinations of these groups rather than directly assigning permissions user-by-user.

---

Documentation Worth Creating

Even if you don't find an exact Crowd example, I strongly recommend documenting:

Document	Purpose
Access Control Policy	Who can approve access
Group Naming Standard	Consistent group structure
User Onboarding Process	Internal and external onboarding
User Offboarding Process	Immediate removal procedures
Access Review Procedure	Quarterly audits
Permission Ownership Matrix	Defines who owns each group/resource

For mixed internal/external Atlassian environments, having a clear group ownership model is often more important than the Crowd configuration itself. The organizations that scale best typically assign an owner to every significant Crowd group and require all access requests to be approved by that owner.