Note: Before all workflows in the enabled JIRA projects are correctly matched with their Hansoft counterparts, no items will be synced to JIRA.
For more information about working with workflows in Hansoft, please consult the Hansoft online manual: Pipelines, Kanbans and Workflows
Feel free to contact us at firstname.lastname@example.org for any integration setup questions you have.
Items in Hansoft do not have workflows linked to them by default, but since all item types in JIRA are associated with a workflow we must replicate the JIRA workflows in Hansoft for the item types the integration will sync.
Syncing workflows automatically
Starting with the 9.1006 version of the integration workflows can be synced automatically from JIRA to Hansoft. To enable automatic sync of workflows check the setting shown below. This setting will affect all views in the Hansoft project as workflows are available in all views.
Any JIRA projects enabled in the 'JIRA project synchronisation' tab will have their workflows automatically created in Hansoft. The name of the workflow will be the same as it is in JIRA.
As long as the automatic sync is active the workflow statuses in Hansoft will be kept identical to the ones in JIRA. Updating the workflow in JIRA will generate the same changes in Hansoft. Statuses can be renamed in Hansoft and transitions can be created, but statuses removed will be recreated by the integration after saving the workflow.
Disabling the sync will allow users to edit the workflow. Manually edited workflows will be copied by the integration before changing it if the sync is reactivated.
Syncing workflows manually
In the example below we will create the standard JIRA workflow in Hansoft.
To help you get started there is an example of the default JIRA workflow in the More.. menu in the workflow editor. You can use this workflow during your initial setup to get an understanding of how the workflow matching is done.
The restriction models in Hansoft and JIRA are too disparate to be automatically setup by the integration. It is therefore important that you map your data flows in the two systems and ensure that the desired restrictions are applied by the system where the data update is triggered.
The workflow matching between JIRA and Hansoft is name based so it is important that both your workflow and all workflow steps are all named exactly like their counterpart in JIRA. There is an option to override this name matching if needed on a per status level. See the "resolution" section below: Resolution settings
In order to get you started the default workflow XML (jira_default_workflow.xml)can be found in your integration install directory. The option to import a workflow is found in the More.. menu in the workflow editor.
The basic workflow
Picture 1 shows the steps of the "jira" workflow, the standard JIRA workflow.
The corresponding workflow in Hansoft would look as picture 2.
At a glance this might look like a bit of a tangle but it is easier if we look at the statuses one by one. Let's take the "Open" status as an example.
The "Open" status is connected to three other statuses, "In Progress", "Resolved", "Closed", through three transitions (Transitions in Hansoft and JIRA differs, see below).
The "Open" status and corresponding transitions (connections in Hansoft) would be setup like in picture 4.
Simply repeat this for the other statuses of your workflow and you are done.
In JIRA, rules for progressing a workflow are setup in the transition connecting two statuses. In Hansoft a connection does not have specific rules, it is simply connecting two statuses. "Transition" rules are setup within the statuses themselves or in a specific "Transition" connection between two statuses.
If we take the setup from picture 2 and say that we want specific data to be filled in for a user to progress the workflow to the next step, we then edit the "Open" status. As seen in screenshot 5 we specify that a new comment must be added to the item before progressing it to the next workflow step.
The new comment will be required regardless of which status the user want to progress to. If we want to make a specific requirement towards a single status we create a "Transition" like in picture 6.
In this transition I now specify that a comment must be filled in in order to progress to the next status. When using a "Transition" I can also specify which users, or groups, that are allowed to make the transition.
In JIRA, "resolution" is a mandatory field for certain workflow statuses. In order to support this, "resolution" must be setup for each workflow step in Hansoft where it is mandatory or where it should be cleared.
We continue the example from above. We now want to make sure that if we complete an item from Hansoft "resolution" is set in JIRA. Right click the "Closed" status and select "JIRA workflow settings".
In this window you now have 2 drop down lists. The "JIRA status" is currently set to match by status name. This is the default setting and the "Closed" status in Hansoft will then be matched to the "Closed" status in the corresponding JIRA workflow. If needed, this menu can be used override the built in name matching and instead link a Hansoft workflow step to a specific JIRA workflow step.
If possible we recommend that you name the statuses the same to avoid unnecessary confusion in your data matching.
The second drop down "JIRA resolution" is used to specify what "resolution" should be set to when the workflow reaches this step in Hansoft. We set it to "Fixed".
The other way around we also need to specify that "resolution" should be cleared when moving from say "Closed" to "New". We then edit the "New" status in and specify that "resolution" should be set to "No resolution".
Repeat this for all statuses where "resolution" is mandatory to be set to a specific value or cleared.
JIRA workflow statuses with multiple resolutions.
As we described earlier you need to map JIRA resolution in Hansoft in order for it to properly propagate to JIRA when progressing workflows from the Hansoft side. In JIRA you can have different resolutions for the same workflow, for example closed with resolution "Fixed" and closed with resolution "Won't fix". If this is the case you need to create a workflow step for each of the alternatives in Hansoft and map the resolutions to match. In order to avoid confusion and make it clear for your users we recommend that you name your Hansoft workflow steps with the resolution to which they are matched.
An example Hansoft QA workflow supporting two JIRA workflows, where one of them has two Closed statuses with different resolutions, could look like this.