ACAccounts in applications
Entra ID to Atlassian integration: Jira and Confluence access from Microsoft Entra ID, also for renamed groups
With an integration between Microsoft Entra ID and Atlassian Cloud, everyone in the right Entra group gets a managed Atlassian account, joins the groups that give access to Jira and Confluence, and the account is deactivated as soon as they go out of scope. KoppelHet sets up provisioning in Entra ID and also handles renamed groups, employees without a mailbox and employee number and location in the profile.
What the integration does
Organisations that manage accounts in Entra ID and use Jira and Confluence in Atlassian Cloud often switch on provisioning from Entra ID. That works until a group in Entra ID gets a new name, a colleague without a mailbox gets no email address, or Atlassian silently skips a change on an unverified domain.
- IT verifies the domains in Atlassian, sets up an identity provider directory and gives KoppelHet the SCIM URL and API key.
- KoppelHet sets up provisioning to Atlassian in Entra ID, with employee number, location and an email source that is filled even without a mailbox.
- Members of the assigned Entra groups become managed accounts in Atlassian, in groups with the same name.
- When an Entra group gets a new name, KoppelHet creates the new group in Atlassian, moves the members and removes the old one.
- When someone goes out of scope or their account is disabled, Entra ID deactivates the Atlassian account.
What to watch for with Microsoft Entra ID and Atlassian Cloud (Jira en Confluence)
- Atlassian cannot rename a group, so provisioning from Entra ID does not pass on a new group name. The old name remains in Atlassian. KoppelHet spots the difference, creates a group with the new name, moves the members and deletes the old group, after the admin has set app access on the new group.
- In Entra ID the mail attribute is only filled when someone has an Exchange mailbox. Colleagues without a mailbox, such as staff with Teams only or external project members, then arrive without an email address. KoppelHet sets a replacement attribute in the mapping, so they still get a working Atlassian account.
- Atlassian links an existing account to an Entra user based on the email address. Accounts colleagues once created themselves with their work address thus become managed accounts with all their issues and pages. KoppelHet compares the Atlassian users with Entra ID beforehand, so a wrong or old address does not end up with the wrong person.
- Entra ID does send changes for users on an unverified domain, but Atlassian does not process them. A colleague who moves to a subsidiary with its own domain even loses their groups. KoppelHet checks which domains occur in Entra ID and reports missing verifications before they cost access.
- Without changes Entra ID only sends username, name, email and status. Atlassian also accepts employeeId as employee number, physicalDeliveryOfficeName as location and a nickname from Entra ID. KoppelHet adds those, so colleagues in Jira and Confluence see where someone works.
- Entra ID matches groups on display name. An Entra group that happens to have the same name as an existing or built-in Atlassian group cannot be created. KoppelHet gives the groups for Atlassian in Entra ID a fixed prefix, so no clash occurs.
How we build and run it
- The integration runs on the KoppelHet platform, hosted in a data centre in the EU.
- Every sync and every error is visible in the functional log; on an error your administrator is notified.
- A change that cannot go through is not half-applied but queued for another attempt.
- KoppelHet is ISO 27001 certified. Data travels encrypted and stays on the platform no longer than needed.
- After go-live we manage the integration and adjust it when your process changes.
- The integration fits next to your existing integration layer. Only the fields in the design are transferred; the platform keeps no register of its own.
Implementation and price
This is not an app you switch on. We build the integration for your organisation on our platform, with building blocks we reuse on every project. So it is custom work that does not start from scratch.
A consultant prepares the intake and analyses both systems. We then record the mapping and exceptions field by field, test in the test or acceptance environment and go live at a moment you choose. Costs are a one-off amount for the setup and a monthly amount for platform, monitoring and support.
Frequently asked questions
Do we need Atlassian Guard?
Yes. According to Atlassian, automatic provisioning from an identity provider requires a Guard Standard subscription.
Can admins still edit groups in Atlassian?
No. Synced groups are read-only in Atlassian. You change membership in Entra ID; which app belongs to a group you set in Atlassian.
Why not directly from the HR system?
If Entra ID is already filled from HR, one source for Atlassian is simpler. Without an identity provider the HR system can be the source; see for example Nmbrs or Workday to Atlassian.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- Entra ID writes through provisioning to the User provisioning REST API (SCIM 2.0) with the SCIM base URL and API key from admin.atlassian.com. Users match on email, groups on displayName; batch PATCH for groups and schema discovery are supported.
- For renamed groups KoppelHet reads groups through Microsoft Graph (delta query on groups) and writes through the same Atlassian API at https://api.atlassian.com/scim/directory/{directoryId}: POST /Groups, PATCH with members and DELETE of the old group. Extra attributes through urn:ietf:params:scim:schemas:extension:enterprise:2.0:User (employeeNumber) and urn:ietf:params:scim:schemas:extension:atlassian:2.0:User (basedIn).
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Microsoft Entra ID | Field in Atlassian Cloud (Jira en Confluence) | Notes |
|---|---|---|
userPrincipalName | userName | |
mail, of userPrincipalName als er geen mailbox is | emails[type eq "work"].value | |
givenName en surname | name.givenName en name.familyName | |
employeeId | enterprise.employeeNumber | |
physicalDeliveryOfficeName | atlassian.basedIn | |
accountEnabled en toewijzing | active | |
Groep (displayName en leden) | Groups (displayName, externalId, members) |
Related
ADP GlobalView → Microsoft Entra ID
ADP GlobalView to Entra ID integration: accounts per country from international payroll
ADP iHCM → Microsoft Entra ID
ADP iHCM to Entra ID integration: accounts from ADP payroll, with the right licence in every European country
ADP Workforce Now → Microsoft Entra ID
ADP Workforce Now to Entra ID integration: Microsoft accounts from ADP, with the work address back in ADP
AFAS Profit → Microsoft Entra ID
Connect AFAS with Microsoft Entra ID