Roadmap and long-term support plans for the Microsoft Entra ID Assets integration (currently Beta)

[Stephen Neil]

Hi all,

I'm considering evaluating the Assets - Microsoft Entra ID Integration for Jira Service Management Assets as it appears to solve a use case we've been looking for: synchronising organisational user information from Microsoft Entra ID into Assets for use in other schemas, object relationships, and automation rules. Atlassian currently describes the integration as being still in development, with functionality and imported data potentially changing without notice, and recommends using it in a separate schema rather than production data. 

Intended use case would be along the lines of:

• Import users and selected Entra ID attributes into Assets
• Reference those user objects from other schemas (devices, departments, locations, approvals, cost centres, etc.)
• Drive JSM automation and workflow logic from the imported data
• Use Assets as a central source of organisational context for service management processes

I'm reluctant to build any critical automations or schema relationships around a capability that remains in Beta.

A few questions for the Assets team:

1. Is there a published roadmap or target timeline for moving this integration from Beta to General Availability?
2. Is Atlassian committed to this integration as a long-term strategic capability for Assets, or is it still considered experimental?
3. Should customers feel comfortable designing production Assets schemas that depend on this integration, or is it still best treated as an evaluation feature?
4. Are there plans to expand the range of imported objects and attributes from Entra ID?
5. Has Atlassian considered making Entra ID a first-class source for organisational data within Assets, similar to how many customers use CMDB/asset platforms as an authoritative reference for people, devices, ownership and approvals?

I'd also be interested in hearing from anyone already using this integration in production:

• How stable has it been?
• Have you encountered any schema-breaking changes?
• Would you use it again for a greenfield implementation?

Thanks in advance.

[Gabriela - LeanZero · Accepted solution]

Hi Stephen,

I can't answer the roadmap half, and I'd be wary of anyone who does, because commitment and GA timing are Atlassian's to state rather than ours to infer. What I can give you is the current documented position and one limitation that bears on your design more than a timeline would.

The exact status wording matters here, because it lands stricter than Beta in one respect: "This integration is still in development, and you may encounter bugs and feature improvements while using this software", and the schema advice is "We recommend using this app in an empty object schema", so empty rather than merely separate from production.

On the scope you asked about, the import already covers more relationship structure than people expect. It brings in User, Group, Enterprise Application, Subscription and Client Secret object types, and Manager arrives as an Object - User reference rather than a string, with Department and Job title resolving to objects too, which is most of the org hierarchy you described wanting.

The thing I'd actually design around is JSDCLOUD-18651: scheduled imports shipped for Assets generally, and that ticket exists because they don't cover Entra ID. It sits at Gathering Interest with 22 votes and was updated yesterday.

How were you planning to trigger the refresh in a production setup?

[Stephen Neil]

Thanks so much for coming back to me.

The reason I'm exploring this is that, prior to migrating from Jira Data Center to Cloud, we synchronised users from Microsoft Entra ID into Crowd and had a nightly process that automatically maintained user objects in Assets. Since moving to Cloud, users synchronise into Atlassian Guard, but we've lost the ability to automatically create and maintain Assets user objects.

Today we work around that by running a manual import process from a CSV export of Entra ID data. It works, but it's operationally cumbersome and creates a delay between a user being onboarded and becoming available as an Assets object. That becomes particularly noticeable where user objects are referenced by devices, approvers, ownership records, departments and automation rules.

The immediate gap I'm trying to solve is automated lifecycle management of user objects inside Assets, rather than simply importing richer organisational data.

At present we don't have any automated refresh mechanism. The process is entirely manual and driven from a CSV export.

I'd love to understand Atlassian's strategic direction for the Entra ID integration. If the intention is for it to become a production-grade capability with automatic synchronisation, I'd much rather build around that than continue investing in custom import processes and workarounds.

On the schema side, the recommendation to use an empty schema doesn't concern me too much architecturally. I'd likely separate people and organisational data into a dedicated schema anyway and cross-reference it from other production schemas. In fact, the richer object model exposed by the Entra ID integration strengthens the case for that approach, as I can see potential future use well beyond my current user object requirements.

I'd happily add my vote to JSDCLOUD-18651, although I'm still trying to understand whether that issue is intended to address refreshes for the Entra ID integration itself, or whether it's related to a different import mechanism. More broadly, I'm interested in whether Atlassian sees the Entra ID integration becoming the long-term authoritative source of organisational data within Assets, or whether Data Manager is intended to fulfil that role going forward.

I'd also be very interested to hear from anyone already using the Entra ID integration. In particular:

• Does it automatically keep imported objects synchronised with Entra ID?
• How frequently are updates reflected in Assets?
• Have you been comfortable building automations and object relationships that depend on the imported data?

The Marketplace listing talks about "staying current by connecting your data from Microsoft Entra ID to Assets", which suggests some form of ongoing synchronisation, but I haven't yet found documentation that clearly explains the refresh model.

[Gabriela - LeanZero]

Hi Stephen,

That reframes it, because the lifecycle problem has a different route than the integration app we were both looking at. Data Manager carries its own Entra ID User data source, and that one runs over an API connection rather than a file, so the CSV export drops out of the picture entirely. It also ships a People object class out of the box, and its default attributes are the lifecycle fields you'd want, including Status, EmploymentType, StartDate, EndDate, ManagerID and Department.

The refresh side takes a schedule at once, daily, weekly or monthly. Read the wording closely though, because Atlassian describes triggering the fetch, transform, cleanse and merge, and the documentation stops at that boundary rather than claiming it pushes anything into your Assets schema. That last hop is a separate Data Manager import pointed at a saved search, and whether it carries a schedule of its own is something I'd open that import and confirm rather than take on my word.

The gate on all of it is that Data Manager only comes with Premium and Enterprise. Are you on one of those already, or would this route need a plan move first?

[Stephen Neil]

Thanks Gabriela, that's really helpful.

We're already on Premium, so Data Manager is available to us. I hadn't appreciated it provided a native Entra ID data source with scheduled refresh capability, and that sounds much closer to the lifecycle management problem I'm trying to solve.

The key question for me now is the final step into Assets. If Data Manager can automatically maintain People objects in Assets from Entra ID data, that may provide a much more suitable long-term solution than my current CSV-based import process.

I'll do some further investigation there.

Thanks again for pointing me back in that direction.

[Gabriela - LeanZero]

Hey Stephen, glad it landed, and Premium makes this a real option for you. On the final step, the piece you want is the Data Manager import inside your Assets schema, which points at a saved search in Data Manager rather than at the data source itself, so your People object class becomes a saved search and that import is what writes the objects. The bit I'd check first is whether that import shows a Create schedule action in your imports list, because that's the one hop the docs don't promise, and if it does you've got the whole loop. If you get there, I'd love to hear how it behaves :)