Jira and Jama
Keep requirements in sync with Jira and Jama in both directions – on a schedule, on a click or as soon as something changes in the tool.
Work in progress. This documentation is not complete yet. If something is missing, write to us: support@wiestigo.com
As of 11 October 2026 · checked against Wiestigo Mirador 0.1.0
Mirador synchronises requirements with Jira and Jama in both directions: it fetches elements from the tool into the project and writes changes back. Relationships are included, attachments and variability on request. So you start alongside your existing tool, without migrating.
Setting up (operations)
To reach a tool, Mirador needs its address and access. Both are entered by the administrator – in the configuration or in the administration, in the Settings section:
| Jira | Jama | |
|---|---|---|
| Address | base address of the REST API, such as https://jira.example.com/rest/api/2/ | address of the Jama instance |
| Access | a bearer token | username and password |
These values take effect after a restart of the model service. A secret can be entered in the settings but is never shown again.
How types, attributes, values and relationships translate between the
tools is defined in one mapping file per tool
(interface_jira_mapping.json, interface_jama_mapping.json). A value
without a translation is skipped and reported.
Create a sync point
A sync point connects a place in the project with a project in the tool. In the directory, choose Exchange → Synchronise:
- Choose the Tool (Jira or Jama).
- Under Sync point, choose New sync point, the place in the project (Select an artifact…) and the Jira project key or the Jama project id, then Create.
The project administrator may create and remove sync points. Removing only cuts the connection; the content stays.
Synchronise
In the same dialog you choose the Direction:
- Fetch from Jira/Jama into RMM, or
- Write back from RMM to Jira/Jama.
And how thoroughly:
- Delta run – only what changed since the last run. Deletions are detected only by a full run or a webhook report.
- Deep sync – also update artifacts that already exist.
- Include attachments, Include variability.
- Check value mapping shows beforehand which values have no translation.
Start synchronisation or Start write-back starts the run; the dialog shows its progress. Anyone who may edit in the project may start one.
Automatically
- On a schedule: under Sync plan the project administrator chooses Every 15 minutes, Hourly, Every 6 hours or Daily.
- On a change in the tool: the tool can notify Mirador through a webhook (see REST API); Mirador then fetches the changed elements.
Scheduled and triggered runs only ever fetch changes from the tool. Writing back happens with the next run in that direction that someone starts.
What you see in the project
- The id from the tool appears as External Id in the table and the detail panel.
- Relationships mirrored in a tool field show their state: stored in the tool, pending (the next outgoing sync writes it), from the tool or RMM only.
- The administrator sees all recent runs in the Sync Runs section of the administration.
When something does not fit
- An element someone has locked in Mirador is skipped and reported in the run.
- An element deleted in the tool is deleted in Mirador by a full run – or only marked, if your operations team sets it up that way. A threshold prevents an error from deleting more than half at once; it applies from three missing elements up. By default the deletion also propagates to the other connected tools unless your operations team switches this off. If the tool reports deleted ids through the webhook, Mirador deletes them at once, without the threshold.