We need clarification regarding the SailPoint ISC standard Atlassian connector’s account creation mechanism and its potential interaction with an existing SCIM provisioning setup.
Primary Questions:
Account Creation Mechanism:
Does the Atlassian connector send an invitation email, or does it perform actual account creation via Atlassian APIs?
What is the exact provisioning behavior during the CREATE operation?
SCIM on EntraID Federation Coexistence:
Can the SailPoint Atlassian connector coexist with an active EntraID SCIM provisioning without conflicts?
If an account already exists in Atlassian (created externally by SCIM), does the connector detect and correlate it instead of attempting a duplicate creation?
Current Customer Environment:
Atlassian Setup: Federated with EntraID (Microsoft Entra ID) with active SCIM provisioning
We have one Atlassian organization with 10 different sites
SCIM Sync Schedule: Every 30 minutes
Scope: All employees are included in the federation and automatically provisioned to Atlassian via SCIM
Concern/Risk Scenario:
We are concerned about potential race conditions and duplicate account creation attempts in the following timeline:
3:00 PM - EntraID SCIM automatically creates an Atlassian account for user j.smith
3:30 PM - Someone requests Atlassian access for j.smith through SailPoint ISC
Result: SailPoint connector attempts to CREATE the account before an aggregation has occurred
Specific Questions:
Will the SailPoint connector’s CREATE operation conflict with the existing SCIM-created account?
Does the connector have built-in logic to detect existing accounts and correlate them automatically, even without a prior aggregation?
What error handling or reconciliation mechanism exists for this scenario?
What is the recommended architecture when both SailPoint and EntraID SCIM need to manage Atlassian accounts?
Requested Guidance:
Best practices for integrating SailPoint ISC with Atlassian when SCIM provisioning is already active
Recommended configuration to prevent conflicts
Whether we should disable SCIM and rely solely on SailPoint, or if coexistence is supported
I have not worked on this connector but in general, ISC will try to create an account and add the role/group to the user but if the user already existed and that was not aggregated during last aggregation, the provisioning request will fail and the request role or group will be added to the users that was requested next refresh after aggregation. so even though the initial request failed, the user should get the role/group later. regarding, invitation, the connector will not send it but after creation, Atlassian will do. To avoid creation conflict, my recommendation is to have ISC create the account, since all employees get the access, as a birthright access to add basic/default access like ‘all users’ group or something.
From what I understand, the account is created via a Atlassian APIS and NO the account onboarding emails are sent by Atlassian and not the connector by itself.
The CREATE account policy determines and assigns the account attributes to the provisioning plan, and the connector uses those values to perform the account creation.
By design, the connector does not perform a pre-existence check or correlation before issuing the CREATE call. If an account with the same native identity value (email) already exists in Atlassian, the Atlassian API will return a 409 conflict response and the CREATE operation will fail.
Atlassian enforces uniqueness based on the email address, a duplicate account would only be created if the user identity were mapped to a different email value which is typically unlikely. Under normal circumstances
Running EntraID SCIM and the SailPoint Atlassian connector as two account-creators is not recommended. Coexistence is only safe if you clearly divide responsibilities (e.g., EntraID does lifecycle via SCIM, SailPoint only manages groups/entitlements or works upstream in Entra).
NO - ISC only correlates that account after aggregation, not dynamically at CREATE time. The connector will attempt a duplicate create account op and fail.
Yes to conflict
No it does not.
This approach is prone to request failures, reconcile on failure and then correlate and then retry access provisioning. (workflows)
Or run aggregations in a smaller time frame (bad idea)
Option 1: Pick one and forsake the other, ISC or SCIM, not both.
Option 2: Leverage both with STRICT SCOPE SEPARATION (eg: SCIM for creation and deletion, ISC manages upstream)
SailPoint → Manages EntraID groups → SCIM → Atlassian applies access
We tried this scenario and it works. So SCIM and Connectors can works together.
The connetors does not correlate the account but the creation does not fail. The connector adds the groups or project without error at the same account created in SCIM.
In our scenario SCIM will create in some sites and Sailpoints in other sites but also if SCIM will create in the same site the connector is working fine.
@sreeram So, you write that there are conflict. You tried or you think that could be confict ? Because we tried the complete scenario with the client and it’s working.
Good that it worked and met the business outcome. However, it is unclear how ISC determined to build the provisioning plan using a Modify Account operation rather than a Create Account operation for a source account whose existence ISC was not aware of.
If the account is not present or known to ISC, the provisioning engine should expand the plan to a Create Account operation, calculate the native identity and other required attributes, and provision the access along with the account.
Would you be open to discussing how the build handled this scenario, or sharing your thoughts on how/why the create account operation worked?