Status Mapping | mgm Marketplace App Documentation

📘 What you will learn here

On this page you will learn how to set up status mapping so that, when a work item moves to a new status on one site, Sync Bridge moves the linked work item through the matching workflow transition on the other site.

This page is for Jira administrators who set up sync rules.

Status isn't copied like a field. Each site has its own workflow, so you map transitions: "when the source moves from status A to status B, move the target from status C to status D". You set this up in the Status card under Special contents on the Field mapping tab of a sync rule.

How status mapping is organized

Level	What it is
Project mapping	One source space on This Jira site, paired with the target space of the rule. Add one for each source space whose work items should sync status.
Work type group	A set of source work types and a set of target work types that share status mappings. All source work types in a group must use the same workflow, and so must all target work types.
Status mapping row	One source transition (From status → To status), one target transition, and a direction.

Set up status mapping

Open the sync rule, go to the Field mapping tab and find the Status card under Special contents.
Turn the card on. It expands to show its settings.
Click Add project mapping. In the dialog, pick the Source project. The Target project is the target space of the rule. Click Add mapping.
In the project mapping, click Add group. The Create work type group dialog opens.
Select the source work types that should share one status mapping and click Next. Then select the target work types the group maps to and click Create group.
On the new group, click Set up.
Click Add status mapping and fill in the row:
- Source side (left): From status and To status. Choose Any status as the From status to match the move into the To status from any status.
- Direction (middle): Source → Target, Both directions or Target → Source.
- Target side (right): From status and To status.
Repeat for every status change you want to sync, then click Done.
Click Save changes.

A collapsed group shows how many of the source workflow's statuses are covered, for example 3 of 7 statuses mapped, and links to the source and target workflows. Click Edit to change a group.

Rules the editor applies

A source work type can be in only one group of a project mapping, and so can a target work type. When all are used, the dialog shows "All source work types are already in a group." or "All target work types are already in a group."
Work types in one group must share a workflow. Otherwise the dialog shows "The selected work types use different workflows. Select work types that share a workflow."
For team-managed spaces, work types must share the same statuses: "The selected work types have different statuses. Select work types that share the same statuses."
Team-managed and company-managed work types can't be mixed: "Work types from team-managed and company-managed spaces can't be in the same group."
To status lists only the statuses that a workflow transition can reach from the selected From status.

Which source spaces you can map

The Source project list depends on the rule's source scope on the Configuration tab:

Source scope	Spaces offered
Basic with Spaces selected	The selected spaces.
Basic with no spaces selected	All spaces on This Jira site.
Advanced JQL	The spaces the JQL can match. Sync Bridge reads the `project` clauses of your JQL, for example `project = ABC`, `project in (ABC, DEF)` or `project != XYZ`, combined with AND, OR and NOT. When the JQL doesn't limit spaces in a way Sync Bridge can work out, for example it uses a function, all spaces on This Jira site are offered.

A space already used in a project mapping isn't offered again. When every space in scope is mapped, Add project mapping is hidden.

How status changes are synced

Push (This Jira site to the other site)

A work item on This Jira site changes status. To react right away, the rule must listen to Status changed or Work item updated under Jira events. A manual or API sync uses the latest status change in the work item's history.
Sync Bridge looks for the project mapping of the work item's space, then for a group that contains both the work item's work type and the linked work item's work type.
In that group, it looks for a row with direction Source → Target or Both directions whose source To status is the new status and whose source From status is the previous status or Any status.
It runs the row's target transition on the linked work item.

Status sync runs only for work items that are already linked. A work item that Sync Bridge creates on the other site starts in the initial status of its workflow.

Pull (the other site to This Jira site)

Each time the rule pulls, Sync Bridge reads the latest status change of the linked work item on the other site since the previous pull. It looks for a row with direction Target → Source or Both directions whose target To status and From status match, and runs the source transition on the work item on This Jira site. If that work item is already in the mapped status, nothing happens.

When no transition matches or exists

Situation	What happens
No row matches the status change, or the work types aren't in a group.	Status isn't synced. Nothing is reported as failed.
The row's transition can't run from the linked work item's current status.	The status sync fails and is recorded in Sync History. Other parts of the sync, such as fields and comments, still run.
Team-managed space with no transition to the target status from the current status.	The status sync fails with "<key> can't move to <status> from its current status. Check the status mapping and the target workflow."
A pulled status change fails.	It isn't retried automatically. Fix the cause and retry the sync from Sync History.

Use Any status as the target From status only when the workflow has a transition that can reach the To status from every status. Otherwise, add one row per From status so that a transition exists for each case.

Workflow data

Statuses and transitions are read live from the workflows of the mapped spaces: from This Jira site for the source side, and through the rule's connector for the target side. A saved row refers to the workflow transition that existed when you selected it, so check the rows again after you change a workflow.