I am looking to implement a one-way sync from Jira Service Management Cloud (Assets/CMDB) to ServiceNow CMDB tables using Exalate, and i need clarification on whether this is achievable and what the recommended approach would be.
My use case is straightforward in concept: we have CIs stored as objects in Jira Assets (organized in object schemas with attributes), and we want those CIs to be pulled and used to populate the corresponding ServiceNow CMDB tables (e.g. cmdb_ci_server, cmdb_ci_business_app, etc.) as records. We are not syncing Jira issues — we want to sync the Assets objects themselves, independently of any linked issue (if possible).
My questions are: (1) Is there a supported or recommended way to have Exalate read directly from Jira Cloud Assets objects? (2) Is the Basic Auth HTTP Client workaround for this use case, and are there any documented examples? (3) Has anyone implemented a Jira Cloud Assets → ServiceNow CMDB pipeline with Exalate.
Any info from the team or community would be greatly appreciated .
Exalate does not support syncing Jira Assets (CMDB objects) as a native entity.
However, this can be achieved using Script Mode with custom HTTP calls to the Jira Assets REST API. This allows you to fetch object data and pass it through the sync payload.
In practice, since Exalate’s synchronization is typically triggered via work items (issues), these scripts are usually executed in that context, even if the actual data being synchronized comes from Assets.
On the ServiceNow side, CMDB tables are supported out of the box, so Exalate can directly create or update records (e.g., cmdb_ci_server, cmdb_ci_business_app) without additional workarounds.
While there is no out-of-the-box template for Jira Assets → ServiceNow CMDB, this approach is commonly used for building custom integrations.
I have a follow-up to clarify the scope of what Script Mode + HTTP Client can actually sync.
If we set up the sync to be triggered by a Jira issue (as you mentioned is the typical pattern), does that mean we are limited to syncing only the Assets object(s) directly linked to that issue via an Assets custom field?
Or, inside the outgoing sync script, can we use the HTTP Client to query the Jira Assets REST API more broadly — for example, running an AQL query to fetch many (or all) Assets objects of a given type — and push them through in a single sync event, regardless of whether they are linked to the triggering issue?
In other words: is the triggering issue just the execution context for the script (so we can fetch anything we want from Assets), or does Exalate constrain the sync payload to only the objects referenced on that specific issue?
If broader bulk fetching is possible, is there a recommended pattern for this — e.g., using a dedicated “control” issue as a trigger for scheduled asset syncs? And are there any limitations we should be aware of (payload size, error handling when one object in a batch fails, etc.)?
Based on the Assets API, it is possible to run an AQL query to retrieve a large number of assets. However, depending on the volume of results returned by the AQL, you may run into payload size limitations.
On the ServiceNow side, there is also some additional complexity. The standard CMDB API typically allows creating only one CI per request. In case of an error, it is also not very clear where exactly the process failed or at which point it stopped creating records. This can easily lead to duplicate CI creation if retries are not handled carefully.
ServiceNow also provides the IRE (Identification and Reconciliation Engine) API, which can be used to create or update CMDB records using a structured JSON payload. However, using this approach would likely require transforming the data coming from Jira Assets into the format expected by IRE, which adds another layer of complexity to the implementation.
You may also find the following documentation helpful:
.