SailPoint × Atlassian Connector
Identity governance connector
Connected Atlassian account data with SailPoint to improve centralized identity visibility and access-review readiness.
The problem
Identity governance is only as good as its account inventory. If the identity platform can’t see an application’s accounts — completely and correctly correlated — access reviews, lifecycle actions and visibility all quietly run on partial data.
For an Atlassian estate whose accounts weren’t flowing in with the required behavior out of the box, that meant building the integration: retrieve every account through the REST API, shape the attributes to the platform’s schema, and match each account to the right human — without ever matching it to the wrong one.
The approach
A custom REST-based connector for SailPoint Identity Security Cloud: paginated account aggregation from the Atlassian API, filtering of non-human accounts, attribute transformation into the account schema, and email-based correlation to existing identities.
The engineering emphasis sits in the unglamorous places — pagination completeness, null and inconsistent attributes, and correlation safety — because a governance connector that silently drops a page or links the wrong person does damage that looks like success.
My role — Connector design and troubleshooting across REST aggregation, filtering, correlation, transformations and attribute mapping.
How it works, step by step
Account aggregation & correlation
The connector pattern, step by step. Identities shown are dummy examples.
01Aggregation request
SailPoint starts an account aggregation — the scheduled pull that keeps the governance view current.
Select any node in the diagram to inspect it.
- This project
- Internal layer
- Connected system
- Data at rest
- Info
- Success
Architecture
Architecture
A deliberately small system: the connector is configuration and mapping logic between two platforms.
- This project
- Internal layer
- Connected system
- This project
- Internal layer
- Connected system
Everything sensitive is externalized by design: credentials live in the source configuration, connector permissions are minimal, and the public description of this work stays at the pattern level — no internal endpoints, filters or payloads.
Key engineering decisions
- Pagination handling
- Account filtering
- Email correlation
- Attribute mapping
- Account aggregation
- Certification readiness
Switch to the technical view for the engineering trade-offs behind these.
Challenges & limitations
- This is professional work described at the pattern level: the actual production filters, attribute maps, tenant endpoints and identities stay private.
- The page claims governance readiness — aggregated, correlated, review-ready account data — and deliberately does not claim specific campaign outcomes.
- Connector behavior described here is the account-aggregation path; broader lifecycle provisioning into Atlassian is out of this project’s scope.
What I learned
Connector quality is decided at the edges — the last page of results, the null attribute, the almost-matching email. The successful API call is table stakes; governance lives or dies on reconciliation of the awkward cases.
Project status
Custom connector work delivered as part of enterprise identity-governance engineering, presented here fully sanitized. Backed by SailPoint IdentityNow Professional & Leader certifications.