How a Work Item Continues the Process
The short version: when the work item of a task is resolved, the process goes on. This page is the fine print behind that sentence. The guides link here when the details matter.
When a Work Item Counts as Resolved
Flower continues the process for a task when a change of its work item sets the resolution. That is the case when Jira reports a change of the work item whose change log contains the field Resolution, and the work item then has a resolution or a status of the category Done.
- A transition into a done status that leaves the resolution empty does not continue a task. Make sure that the Done transitions of your workflows set a resolution (most do).
- For a sub-process instance (the work item of a call activity), a change of the status into the category Done counts as well, on Forge and Data Center. The Connect app is told only about changes that set a resolution (or change the assignee), so there the resolution is needed too.
- Resolution set by Flower: when Flower resolves a sub-process instance at its end, it also sets the Jira resolution if the workflow does not. If the field Resolution is on no screen of the work type, Flower still resolves the work item, writes a warning comment, and continues the calling process on the change into the done category (Forge and Data Center). Without a resolution, JQL (
resolution is EMPTY), the timer job, and reports treat the work item as open. - A work item that Flower has already handled (cancelled by a terminate end event or an interrupting timer or escalation, or resolved by Flower itself) does not continue the process again.
- Other changes of an open work item (fields, assignee, comments) do not move the process. A status change can trigger an escalation.
The Order of Checks When a Work Item Is Resolved
When a work item is resolved, Flower checks the boundary events of its task in this order:
- Error boundary event: if the status of the work item has the name of the error of an error boundary event (for a sub-process instance: the error of the error end event that ended it), the process takes the error path. Nothing else is checked: the conditional boundary events of the task are not evaluated.
- Conditional boundary events: each condition is evaluated with the resolved work item as
cur. An interrupting event whose condition is true takes over the flow; a non-interrupting one starts its path in addition. - Normal flow: unless an interrupting event took over, the process follows the outgoing sequence flow of the task.
Status names are compared without case, accents, apostrophes, hyphens, underscores, and extra spaces: Won’t Do, WONT DO, and Wont-Do are the same.
What cur is in each situation is listed in Expressions.
Escalation: A Status Change of an Open Work Item
An escalation boundary event fires when the work item of its task is moved into the status of the event while it is open: the work item has no resolution, and the new status is not of the category Done. The status can be of the category To Do or In Progress.
- Non-interrupting: the escalation path starts, the work item stays open and can escalate again later.
- Interrupting: the escalation path starts, and Flower cancels the work item (see Which Status Flower Sets). For a sub-process instance, the sub-process and its open work items are cancelled.
- If the boundary event no longer waits (the task has already ended), nothing happens.
Escalation boundary events work on Forge and Data Center, not in the Connect app, see Limits and Host Differences.
Repetitions and Duplicates
- Events of one process instance are handled one after the other, also when Jira reports several changes at the same moment, and on Forge and Connect also against the timer job. See Events of One Process Instance.
- A duplicate event changes nothing: if Jira reports the same resolution twice, the second one has no effect, because the engine works on the state of the process instance.
- A timer fires once per run of the timer job. A second run on the same day fires nothing new, a repeating timer fires at most once a day, and a run that was missed catches up once. See The Timer Job.
- The values Flower keeps on the process instance (the next timer
flowerTimer,flower.waitsForCondition, the reported expressions) are written one after the other at the end of a run, so no value is lost; the other steps of the run (creating work items, comments) then run at the same time. - A problem in an expression is reported once per process instance, not with every change, see Expressions.
Loops: A Task That Runs Again
When the flow leads back to a task whose work item already exists, Flower reopens that work item instead of creating a new one: it uses the first transition without a screen into a status of the category To Do, or else In Progress. If the workflow offers no such transition, the process instance gets an error comment. A loop back into a node whose work item runs as a sub-process instance (a call activity, or a task whose work type is mapped to a model) is not supported (error comment Loop into the node … is not supported, because it runs as a sub process), see Known Issues. A loop back into an embedded sub-process reopens its tasks.
The same applies when a model is not marked executable and a user has created the work item of a task in advance: the engine uses that work item and moves it to To Do, see Create Work Items in Advance.
Which Status Flower Sets
Users complete the work items of tasks; Flower never resolves them in the normal flow. Flower changes a status only in these cases:
| Case | What Flower does |
|---|---|
| The process instance has ended (the last branch reached an end event) | Resolves the process instance |
| A terminate end event is reached | Cancels all open work items and sub-process instances, then resolves the process instance |
| The flow loops back to a task | Reopens its work item (see above) |
| An interrupting escalation fires | Cancels the work item of the task |
| An interrupting timer or escalation fires on a call activity or an embedded sub-process | Cancels the sub-process instance and the open work items inside |
| An interrupting timer fires on a task | Cancels the work item of the task, see Interrupting Timer on a Task |
How Flower chooses the status and the resolution:
- Resolve: the first transition into a green (done) status named Done, Resolved, or Closed, else the first green one; the resolution Done, Resolved, or Fixed, else the first one Jira allows.
- Cancel: the first done status with one of these names, in this order: Canceled, Cancelled, Cancel, Aborted, Withdrawn, Rejected, Declined, Discarded, Obsolete, Won’t Do, Won’t Fix, the German, Spanish, French, Italian, Dutch, and Polish equivalents, and finally Closed; if the workflow has none of them, the first done status. The resolution Won’t Do first, then Cancelled and similar names, else the first resolution Jira allows.
- Resolution: if the transition does not set a resolution, Flower sets it with an edit. If that is not possible, the process instance gets a warning comment (Flower has resolved …, but the Jira resolution is empty …): without a resolution, the work item counts as unresolved in JQL, reports, and the timer job.
A Path Without an End Event
A branch that ends at an element without an outgoing flow (and that is not an end event) stops there. The process instance is resolved only if another branch reaches an end event and no branch is still running. The validator warns about it (This path does not end in an end event …).
Creating Work Items
Space, Work Type, Parent
- Space and work type: the activity, then its swimlane, then the defaults of the Flower Settings, see User Tasks.
- Link: each work item is linked to its process instance.
- Parent: Flower makes the process instance the Jira parent of a work item when both are in the same space and Jira allows it: when the work item is a sub-task type, or (Jira Cloud) when the process instance is one hierarchy level above it, for example an epic, or when the process instance has the work type Initiative. In Data Center, Flower sets the Epic Link when the process instance is an epic in the same space. A sub-task work type in another space than the process instance cannot be created as a sub-task: Flower uses the default work type and writes a warning comment. The validator warns about such sub-tasks.
Mandatory Fields
When Flower creates a work item, nobody fills in a screen. Flower fills the required fields of the create screen as far as it can:
- required text fields get the summary of the work item (or Flower),
- required fields of other types (select lists, numbers, dates, …) stay empty, and Jira refuses to create the work item. The process instance gets an error comment, and the process stops at this task.
The validator marks required fields without a default value red (Mandatory fields are not allowed) only for activities that set their own space and work type; work types inherited from the lane or the Flower Settings are not checked. Wait for data with a conditional start event instead.
Assignee
A work item gets the assignee of its swimlane: the assignee of the most recently updated assigned work item of the lane in this process instance. Work items that are already open keep their assignee, and a reopened work item keeps its assignee too. If the assignee field is not on the screen, the work item stays unassigned.