# Azure DevOps pipeline → update a rich-text table in multiple existing Jira issues using Exalate

**URL:** <https://community.exalate.com/t/azure-devops-pipeline-update-a-rich-text-table-in-multiple-existing-jira-issues-using-exalate/8470>\
**Category:** General Questions\
**Tags:** exalate\
**Created:** [October 28, 2026, 5:31pm UTC](https://community.exalate.com/t/azure-devops-pipeline-update-a-rich-text-table-in-multiple-existing-jira-issues-using-exalate/8470 "2026-10-28T17:31:15Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![exalate\_user](https://avatars.discourse-cdn.com/v4/letter/e/e495f1/32.png) [@exalate\_user](https://community.exalate.com/u/exalate_user)\
**Post date:** [October 28, 2026, 5:31pm UTC](https://community.exalate.com/t/azure-devops-pipeline-update-a-rich-text-table-in-multiple-existing-jira-issues-using-exalate/8470/1 "2026-10-28T17:31:15Z")

</div>

Hi,

I’m looking for some advice on whether Exalate can support an Azure DevOps → Jira integration that is slightly different from the usual one-to-one work item synchronization.

**What we’re trying to achieve**

We have an Android build pipeline running in Azure DevOps.

When the pipeline creates a new APK, we want to update a custom **Build information** field (customfield\_1234) in all Jira issues related to that build.

The purpose is simple: **testers looking at a Jira ticket should be able to see the latest Android build containing that change and download it.**

Azure DevOps is the source of the update, and this is **one-way only: Azure DevOps → Jira**.

**Information produced by the pipeline**

For each build, the pipeline already determines:

- The affected Jira issue keys, for example JIR-123, JIR-124, JIR-125
- Build name, for example 1.2.0-5678
- A link to the APK in Azure Artifacts
- Environment, for example Development, Integration, or Production

The pipeline already contains the logic for identifying which Jira issues are associated with the build.

**Updating the Jira field**

Each affected Jira issue has a rich-text custom field called **Build information** (customfield\_1234).

For the purposes of this question, assume that this field contains a single table such as:

| Environment | Build |
| --- | --- |
| Development | 1.2.0-5677 |
| Integration | 1.2.0-5676 |
| Production | 1.2.0-5677 |

If a new build is generated for **Integration** , for example:

- Build: 1.2.0-5678
- Environment: Integration
- APK: https://…

we want to update **only the Integration row** in each affected Jira issue.

The build name in the second column should also be a hyperlink to the APK.

If the Integration row doesn’t already exist, it should be added. If the field/table doesn’t exist yet, it should be created.

The current implementation already does this successfully by reading customfield\_1234 through Jira’s REST API, manipulating its Atlassian Document Format JSON, and writing the updated value back.

**The complication: we don’t use Azure DevOps work items**

Our development teams use Jira for work tracking, not Azure DevOps Boards.

Therefore, there isn’t an Azure DevOps work item corresponding to each Jira issue.

The event we effectively want to process is a **pipeline/build run** , and one build can apply to **multiple existing Jira issues**.

For example:

Azure pipeline

```
  |

  | Build 1.2.0-5678

  | Environment: Integration

  |

  +--> JIR-123

  +--> JIR-124

  +--> JIR-125

```

**Possible Exalate approach**

One option we’ve considered is having the pipeline create an Azure DevOps work item representing the **build event** , with information along these lines:

{

“ticketIds”: [

```
"JIR-123",

"JIR-124",

"JIR-125"

```

],

“buildName”: “1.2.0-5678”,

“buildLink”: “https://…”,

“environment”: “Integration”

}

Exalate would then somehow need to use that information to update the existing Jira issues listed in ticketIds.

Once processed, the Azure DevOps work item could simply be marked as completed.

We’re not committed to this design. It’s just one possible way we thought of providing the pipeline-generated information to Exalate.

**Questions**

What we’d like to understand is:

1. **Can Exalate use one Azure DevOps work item/event to update multiple existing Jira issues?**
2. Can the list of target Jira issues be determined dynamically from Jira issue keys supplied in an Azure DevOps field, rather than having a predefined one-to-one Exalate relationship?
3. On the Jira side, **can an Exalate script read the existing value of a rich-text custom field, modify it (by updating the row or creating a new one) of an Atlassian Document Format table, and save the updated field?**
4. If this architecture doesn’t fit the way Exalate is intended to work, **is there a better Exalate-supported pattern for passing pipeline-generated information to multiple existing Jira issues when there are no corresponding Azure DevOps work items?**

Our main requirement is essentially:

**Pipeline produces build → pipeline identifies Jira issues → latest build for an environment is added/updated in the Build information table of each Jira issue.**

We currently achieve this by calling Jira’s REST API directly from the pipeline, but we’re investigating Exalate so that we don’t have to manage Jira API credentials within our Azure DevOps pipeline. That aligns with our internal preference for centrally managed integrations rather than independently created API credentials.

Any advice on whether this is possible with Exalate, and what the recommended architecture would be, would be greatly appreciated.

Thanks!

---

<div class="post-metadata">

**Author:** ![Aida](https://dub1.discourse-cdn.com/flex018/user_avatar/community.exalate.com/aida/32/580_2.png) [@Aida](https://community.exalate.com/u/Aida)\
**Post date:** [October 28, 2026, 5:31pm UTC](https://community.exalate.com/t/azure-devops-pipeline-update-a-rich-text-table-in-multiple-existing-jira-issues-using-exalate/8470/2 "2026-10-28T17:31:23Z")

</div>

Great questions! Here’s a breakdown of what’s possible with Exalate for your scenario, based on current documentation and best practices:

1. **Can Exalate use one Azure DevOps work item/event to update multiple existing Jira issues?**

2. **Can the list of target Jira issues be determined dynamically from Jira issue keys supplied in an Azure DevOps field, rather than having a predefined one-to-one Exalate relationship?**

3. **On the Jira side, can an Exalate script read the existing value of a rich-text custom field, modify it (by updating the row or creating a new one) of an Atlassian Document Format table, and save the updated field?**

4. **Is there a better Exalate-supported pattern for passing pipeline-generated information to multiple existing Jira issues when there are no corresponding Azure DevOps work items?**

**Summary:**

- Exalate can support your scenario with advanced scripting in Script Mode, but it’s not a native, out-of-the-box feature.
- You’ll need to write custom sync scripts that parse your Azure DevOps work item, extract the list of Jira issues, and update each one’s custom field—potentially by invoking Jira’s REST API from within the script.
- Manipulating ADF for rich-text fields is possible but requires careful handling.

For more details and script examples, check out the [Script Mode documentation](https://docs.exalate.com/docs/script-mode-overview) and [custom field handling](https://docs.exalate.com/docs/updating-custom-fields).

If you need help with specific script examples or want to discuss the architecture further, let me know!