Configuration

Set default values to link Flower with Jira

Flower app does not come with an own data storage, all data (BPMN models, process instances, etc.) have to be saved as Jira tickets. To create a ticket, Jira needs to know project and issue type - therefore we have to tell Flower which values for those parameter should be used for each entity type. Flower handles 3 different object types:

• The BPMN model is the graphical representation of you process. It is saved as a Jira ticket which contains all versions of a Flower process.
• A process instance will be created when clicking on the play button at your BPMN model. It is saved as a Jira ticket.
• It creates a task for each activity in your BPMN model when starting a process instance. Indeed, a task is a Jira ticket. By default, project and issue type are used from the global Flower settings, but it can be specified separately at each activity in your BPMN model as well (see Process Instances).

These values are managed by a business process owner. Access is not limited to a Jira administrator.

Jira Issue Type Mapping

Similar to a Jira workflow schema that defines a set of associations between a Jira workflow and an issue type, you can also associate a Flower process with a Jira issue type. This can be done on the Issue Type Mapping tab in the Flower Settings section as follows:

Each time you create a problem with the selected issue type, Flower starts a process instance in the background and associates it with the issue you just created.

Advanced preferences

You can partially deactivate version control. In principle, all Flower process instances are started with the last published model version and changes to the model do not affect instances that have already been started or even finished. This behaviour can be deactivated here so that changes to the model not only affect new instances, but also directly all running (and finished) instances.

Particular caution is required here, as editing running process instances entails potential dangers, especially if nodes that have already been run through are deleted. The following effects arise:

• Jira issues that have already been created remain in place and are no longer tracked by Flower
• Gateway decisions that have already been made are not corrected
• Events that have already been fired are not cancelled
• Completely finished process instances also appear with the updated process model

This feature is experimental

Jira Workflow Validator

Per default you can create and resolve all Flower tasks as you want without restrictions. However, you may want to ensure that all tasks are completed in the order described in your BPMN model. To do this, you need to tell Jira that transitions are not allowed until all previous tasks are also marked as completed.

For this purpose, Flower provides a Jira Workflow Validator, which can be added to any transition in your Jira workflow:

It applies only for Flower related tasks and allows the transition to be taken only if there are no open previous tasks. Otherwise, an attempt to resolve the task will fail with an error message.

NOTE

• The Flower Workflow Validator only applies to Flower related issues. All other Jira issues remain untouched.
• You need to be Jira administrator to edit a Jira workflow.
• The validator condition is calculated based on the issue links attached to the Flower process instance (which is also a Jira issue). This means that the validator only takes existing issues into account. BPMN activities without a Jira ticket are not affected, nor are manually deleted issue links.
• Instead of the above described Flower Workflow Validator you can also use the Flower Workflow Condition, which works the same way as the validator but hides the "resolve" button completely.
• If you want to learn more about Jira workflow validators and conditions, check out this documentation (opens in a new tab).