Limits and Host Differences
Flower BPM for Jira comes in three variants: the Forge app (Jira Cloud, the current Cloud app), the Connect app (Jira Cloud, the previous Cloud app, see Moving to Atlassian Forge), and the app for Jira Data Center. All three run the same process engine, so a model behaves the same everywhere, with the differences listed here. The guides link to this page instead of repeating them.
Features
| Feature | Forge | Connect | Data Center |
|---|---|---|---|
| Throw events | Trigger a Jira Automation rule: property flowerAutomation and comment Flower Automation Event: <name> on the process instance (the default, no webhook) | Call the webhook URL of the event (HTTP POST) | Call the webhook URL of the event (HTTP POST) |
| Webhook URL rules | No webhooks: a webhook URL in a model adds the error comment Web service calls are not available in the Forge app | https:// only, public addresses only, no redirects | Also relative paths (to the Jira base URL) and internal addresses |
| Request type Jira Automation in the model | The only option, and the default | Not offered in the modeler; a model from Forge with this request type sets the property and comment as on Forge | Same as Connect |
| Throw event without a webhook URL | Triggers Jira Automation | Error comment (Webhook URL is empty), the process goes on | Error comment (Webhook URL is empty), the process goes on |
| Escalation boundary event (status change of an open work item) | Yes | No: Jira reports status changes without a resolution not to the Connect app | Yes |
| Intermediate and start conditional event (waits for a change of the process instance) | Yes | Only checked when the process instance runs for another reason, for example when a parallel task is completed | Yes |
| Conditional and error boundary event (checked at the resolution) | Yes | Yes | Yes |
| Flower REST API | Only for sites that moved from Connect; a site with the Forge app alone uses the Jira REST API | Yes, see REST API | No, use the Jira REST API |
BPMN file attached to the model on publish (<MODEL-KEY>.bpmn) | Yes | No | No |
| JQL fields | All, see JQL | All | Without flowerNext, flowerPrevious, and flowerMigration |
| Parent of a work item | Jira hierarchy: sub-task, or the next level above (for example epic) in the same space | Same as Forge | Sub-task, or the Epic Link when the process instance is an epic in the same space |
The Timer Job
The timer job makes due timers fire. When it runs depends on the host:
| Forge | Connect | Data Center | |
|---|---|---|---|
| Automatic run | Once a day (a scheduled trigger of Forge; Atlassian chooses the time of day) | Every day at 00:00 UTC | When Jira starts or the app is enabled, then every 24 hours |
| Run by hand | Flower Settings, Jira administrators | Flower Settings, Jira administrators | Flower Settings, Jira administrators (POST /rest/flower/latest/service/runTimerJob) |
| Day of a timer (see Timer Events) | The day in the time zone of the Forge function, usually UTC | The day in the time zone of the Flower server, usually UTC | The day in the time zone of the Jira JVM |
| How due instances run | One queue job per due process instance, with the lock of that instance | All due instances at the same time, each in the lock of its instance | All due instances at the same time, not yet in the lock of the instances (known issue) |
Settings
| Forge | Connect | Data Center | |
|---|---|---|---|
| Who can change the settings | Jira administrators | Jira administrators | Jira administrators (other users get 403) |
| Who can read the settings | Every signed-in user (the Flower pages need them) | Every signed-in user | Every signed-in user; users who are not administrators without the secrets (personal access token, password) |
| Where the settings and the work type mapping are stored | Forge storage of the app on Atlassian (KVS) | The database of the Flower server | Jira’s plugin settings in the Jira database |
| Extra settings | None | None | User or personal access token, base URL, see Flower for Jira Data Center |
Models, process instances, the state of the engine, and all tasks are Jira work items and work item properties on every host, see Data Residency.
Events of One Process Instance
Flower handles the events of one process instance (a resolved work item, a changed process instance, a due timer) one after the other, never at the same time. On Data Center the timer job does not take this lock yet. Which instance an event belongs to:
- a work item belongs to its process instance,
- a process instance belongs to itself,
- a sub-process instance belongs to its calling process instance when it is resolved or its status changes, otherwise to itself.
| Forge | Connect | Data Center | |
|---|---|---|---|
| How | Queue with one concurrency key per process instance | A queue per process instance in the Flower server; the lock is released after 10 minutes if a run does not end | One of 64 locks, chosen by the key of the process instance, in the Jira node; four threads handle the events |
| An event that cannot be handled yet | When the app cannot read the site settings yet (during the move from Connect), the event goes back to the queue every 60 seconds, up to 30 times, in the order of the instance |
In a Data Center cluster, the lock holds within one Jira node.
After the move from Connect to Forge, the Forge app sends every work item that was resolved in the 24 hours before the move (at most 500) to the engine once more, so that no resolution from the switch-over is lost. A resolution that was already handled has no effect the second time.
Limits
| Limit | Forge | Connect | Data Center |
|---|---|---|---|
| Size of the Flower settings (including the work type mapping) | 200 KB | ||
| Time of one run of the engine (an event or one instance of the timer job) | 900 seconds (Forge function timeout) | A hanging run releases the lock of its instance after 10 minutes | |
| Webhook of a throw event | No webhooks | POST; if the target answers 405, Flower sends a GET | POST; if the target answers 405, Flower sends a GET |
| REST API | 20 requests per 10 seconds per IP address |
Language
Flower speaks the language of the Jira user, not the language of the site. Every user sees Flower in the language of their own Jira profile: English, German, Spanish, French, Italian, Portuguese, Japanese, Chinese (simplified), Korean, Dutch, Polish, Russian or Turkish. For any other language, Flower is shown in English.
The BPMN modeler (palette, context menu and messages) is translated for German, Spanish, French, Italian, Portuguese, Japanese, Chinese, Polish and Russian. In Korean, Dutch and Turkish the client is translated and the modeler palette stays in English. Right-to-left languages such as Arabic and Hebrew are not offered yet.
Usage Analytics
Flower sends usage data (which features are used, errors) to PostHog to improve the app. What it contains depends on the Flower app:
- Forge (Jira Cloud): the site as its Atlassian cloud id, the user as the Atlassian account id, and the language of the user as a two-letter code (an event property). No other data of the user (no names, e-mail addresses, avatars), no titles, keys, or content of work items.
- Connect (Jira Cloud) and Data Center: the browser client identifies the user by the Atlassian account id together with the profile that Jira gives the app (display name, avatar) and the language. Some events carry the name of the model that was created or published. No content of tasks or process instances. The Data Center engine sends no usage data.
A Jira administrator can switch usage data off in the Flower Settings, tab Analytics. Then neither the browser client nor the engine sends any. Exception on Forge: the events of the app itself (installed, updated, and the problems of the move from Connect) are sent before any settings exist, so the switch does not apply to them. They carry only the cloud id and the version of the app.