Customer(s) - Provider(s)

Owned by Łukasz Krupa (Unlicensed)
Last updated: May 02, 2017 by Piotr Mazij (Unlicensed)

We want to communicate with Customers or Providers via our JIRA instance.

This scenario can be described as:

  • we are The Provider and synchronize with many Customers
  • we are The Customer which cooperate with many Providers
  • (mix) we synchronize with Providers and other Customers

For better transparency we will describe the 2nd scenario.

Prerequisites

There are several JIRA instances:

  • Master 
    That is our's company JIRA instance that will be synchronized with many other Providers. We can loggin and work only with that instance.
  • Slave
    Providers' JIRA instances. They don't know each other but they all connect to our Master JIRA.

Each JIRA instance will have different configuration because they are managed by different parties.

Communication model

Use DUAL-MODE or BROADCAST.

Realization

For each Provider's JIRA we need to setup Connection & Contract (see Connection & Synchronize 101).


Configuration details

Internal

External

Internal

External

Field Mapping should contains all data that describes a ticket.

Optionally you can synchronize Comments and Attachments.


Corresponding settings should be set.


There is a lot of outgoing tickets. You can consider to synchronize some fields on Update event but more likely synchronize comments and Workflow.

There is no outgoing tickets - Create issue trigger should be left empty.

Update trigger can be used to keep the other side up to date. Alternatively you can don't sent any feedback unless you reach given status (i.e. Resolved) and then propagate your changes (use workflow transition event).

You may want to keep the other side to follow some of your workflow, for example to inform if ticket was analyzed, in progress, tested, resolved (see Workflow Synchronization).

Consideration

    • Based on security level you can consider different project structures and issue permissions. 
      • We suggest to create JIRA project for each Provider you synchronize. It is good mostly for two ways synchronization.
      • If you it is more likely that you are pushing side (only you create tickets) then you may consider to handling that in single project with dedicated issue types for each Provider.