Status Synchronization

Your JIRA workflow can be synchronized:

one-to-one (assuming remote workflow is same as local)
partially at some defined status transitions

Here is an example of two different workflows synchronization. You may notice that:

Open → In Progress is mirrored
If someone will click in progress, it will be reflected in second JIRA.
Closed → Open is one way
Only if left side will reopen issue, the transition will be executed on remote JIRA.

Workflow transitions are made on behalf of Technical User.

How it works

Basics

You are configuring workflow mapping inside your synchronization scheme.

Workflow mapping is a configuration of synchronization scheme and Jira's Workflow.
All contexts from your synchronization scheme using some Jira Workflow will use shared (by synchronization scheme) workflow mapping configuration.

Jira's Workflows are automatically found by project and issue type configured within contexts.

If all local contexts (projects & issue types) are using the same workflow you will be able to configure shared transitions just once for whole synchronization scheme
if your local contexts are using different workflows then you will configure workflow mappings separately per each workflow used by contexts

Exposing local transitions to remote issue.

You can configure which status changes (based on possible transitions) from your desired workflow you want to synchronize.

You have to set pair of statuses, which reflects status change (transition) i.g. from TO DO to IN PROGRESS.

When a user will transition an issue IssueSYNC will check Expose configuration and when there will be a match, it will send proper information to remote issue.

Resolution

By default resolution is always *[1] send as a metadata of transition mapping to remote issue.

[1] Resolution is send only when transition sets a resolution.

Receiving transitions from remote issue.

Once a remote issue has been transitioned and your issue has received a information about that IssueSYNC will look for a Received workflow mapping configuration.

It is quite similar to Expose workflow mapping configuration but here you defined exact transition *[2]. Once remote transition has taken place you will receive a code i.g. "To Do → In Progress" and you have to map this remote transition to your local one. In order to make it easier for you to configure you select base status "from" in Local From Status, which is followed by a transition from this base status. In Local To Status you have to select local transition which is displayed in a "transition name >> STATUS NAME" (same as Jira workflow text form).

Once receiving a transition from remote Jira, IssueSYNC will look for configured local transitions for matching remote transition.

Configuring more than one local transitions for the same remote transition

IssueSYNC mechanism will check for actual issue state and validate which transition is valid for current issue state and only that one will be performed. In more than one transitions will be possible, then first on the list will be invoked.

Resolution

By default IssueSYNC will always receive resolution from remote issue (see expose section). IssueSYNC will check if resolution should be added to transition request. If such transition contains a resolution field, IssueSYNC will validate if such resolution exists (by name and name translations matching) and if not it will try to create such resolution in your Jira.

[2] Instead of pair of status change.

Triggers in workflow transition

Workflow transition (post-function event) can trigger :

Create remote issue
When issue reach given stage it can be replicated (for example in Service Desk: forward to 3rd line support).
Update remote issue
You don't need to synchronize all field changes over and over but maybe at some point in workflow you may want to push that changes to remote JIRA.

Limitations

There are some limitations you need to consider:

Expose transitions are defined between two statuses. You CANNOT point given transition if there is more than one transition between two statuses.
Receive transitions (local transition) will fail when there is a field screen with required field *[3] associated with desired local transition, look here for workaround.

[3] Other than resolution

IssueSYNC versions up to 3.0.x

Show details...

101 Creating workflow mapping

1. In JIRA1 create new worklow mapping:

a) click Add in Workflow Mapping Scheme

b) enter Name (1) and select Workflow (2)

c) enter Outgoing transition code (3)
It requires at least one value to make this workflow mapping visible to the remote.

d) click Save

2. In JIRA2 create new worklow mapping:

a) click Add in Workflow Mapping Scheme

b) enter Name (1) and select Workflow (2)

c) enter Outgoing transition code (3)
It requires at least one value to make this workflow mapping visible to the remote.

d) select Remote workflow mapping (4) (from step 1)

e) select Incoming transition code (5)

f) click Save

3. In JIRA1 edit worklow mapping (from step 1):

a) select Remote workflow mapping (4) (from step 2)

b) select Incoming transition code (5)

c) click Save

Please, keep in mind to enter some incoming transition code, if you want given status to be synchronized.

Resolution

Resolution is sent when the flag is enable.

You are required to have the same resolutions list in both JIRAs.

Limitations

There are limitations you need to consider:

Outgoing transitions codes are defined between two statuses. You CANNOT point given transition if there is more than one transition between two statuses.
Incoming transitions codes have to combined with transitions rather than statuses. So it is opposite to limitation mentioned above.
If you select the same transition codes for several incoming transition, only first will be executed.
That behavior can differ between Server and Cloud version of the IssueSYNC plugin.

Workaround to differentiate outgoing transitions:

Starting situation:
"In Progress" -reject-> "Close"
"In Progress" -approve-> "Close"
=> only one event text possible

Add new intermediate status:
"In Progress" -reject-> "Reject" -(auto*)-> "Close"
"In Progress" -approve-> "Close"

* JIRA Automation plugin (for Server) can listen on given event that will be triggered via workflow transition (you will need to define new event and change post-function from Generic Event to this new one). JIRA automation action executes transition to "Close".
You should not map (auto) transition in your workflow mapping in IssueSYNC plugin - it can be automated on both sides.