Moving to Atlassian Forge

Flower for Jira Cloud is moving from Atlassian Connect to Atlassian Forge. Forge is the platform Atlassian builds all new apps on, and Connect is being phased out (end of support: January 31, 2027 ). For you, this is an update of the same app: same name, same listing on the Atlassian Marketplace, same license.

For the background from Atlassian, see How to adopt Forge from Connect .

What stays the same

• Your data. Flower keeps everything in Jira (work items and their properties). The update does not move or copy it.
• Your running processes. Process instances that are running continue where they stopped.
• Your models and settings. Models, the Jira work type mapping and the Flower settings are taken over on their own. You do not enter them again.
• Your license. A paid license stays paid, an evaluation continues. The update does not start a new trial and does not ask you to buy again.
• Your REST API calls. The public Flower REST API keeps working with your API token. One thing changes: see Flower REST API.

What gets better

• Security. Forge runs inside Atlassian’s infrastructure. Atlassian handles authentication, the app only gets the permissions it asks for, and every update is reviewed by Atlassian.
• Your data stays with Atlassian. The app runs inside Atlassian’s infrastructure and keeps its data in your Jira.
• Fewer moving parts. The process engine runs in Atlassian’s cloud next to your Jira.
• A future-proof app. Connect receives no new features and its end of support is set. Forge is where Atlassian invests.

What you need to do

Most sites need one click.

1. A Jira administrator opens Apps > Manage apps (or the Marketplace page of Flower) and sees an Update for Flower.
2. Atlassian may show a screen to approve the permissions of the app. This is the standard Atlassian screen, you only need to read it and confirm.
3. After the update, open Flower once. Your repository, models and settings are there. That is all.

If you do nothing, your site keeps running the current Connect version until you update. We recommend to update well before Connect reaches its end of support.

Flower REST API

If you call the Flower REST API (for example to start process instances or to read a model), two things change. They are explained in detail on the page Flower REST API.

1. Later, the call will run with the permissions of your API user. Today they do not matter. The user needs the usual Jira permissions to read and create the work items of the process instances and the models. We announce the date in the changelog.
2. Later, the Flower endpoints will be switched off, because everything can be done with Jira directly: start a process by creating a work item of a mapped work type, and read the BPMN of a model from its attachment. We announce the date well ahead of time.

Throw Events with a Webhook URL

The Connect version of Flower can call a webhook URL from an intermediate throw event (message, signal, escalation, and so on), for example to start a Jira Automation rule with an incoming webhook or to call your own service.

The Forge version runs completely inside Atlassian’s infrastructure and sends no data to other servers. This is why it cannot call a URL. After the update, a throw event that still has a webhook URL does not make the call. Flower adds an error comment to the process instance instead, with the text Web service calls are not available in the Forge app. The process itself goes on.

What to do for every throw event with a webhook URL:

1. Open the model and set the Request Type of the event to Jira Automation. There is no webhook field then.
2. Create a Jira Automation rule that reacts when the event is reached: Flower sets the work item property flowerAutomation on the process instance and adds a comment Flower Automation Event.
3. If the rule has to call an external service, use the action Send web request in the rule.

The page Sync Magic describes the rule step by step. You can change the models before or after the update, and publish them again. Events without a webhook URL work as Jira Automation events right away.

Check the Permissions of the Flower App User

Flower creates and resolves the work items of a process in the background, as its own app user (shown as Flower). In Jira Cloud, Jira gives this user access to your spaces with the project role atlassian-addons-project-access. The Forge version has an app user of its own, a new account.

If you gave the old Flower app user permissions directly, for example in a permission scheme of a space, check after the update that the new Flower app user has the same access in every space where processes create work items. If it does not, a process cannot create its work items there. Flower then adds an error comment to the process instance.

• Keep the project role atlassian-addons-project-access in the permission schemes of these spaces.
• Search the permission schemes for the old app user, and give the new one the same permissions.

Flower for Confluence

The Confluence app of Flower (macro Flower BPMN Viewer) moves to Forge as well. It is also an update of the same app: same listing on the Atlassian Marketplace, still free.

What stays the same

• Your pages. Every Flower BPMN Viewer macro on your pages keeps its model or its attached BPMN file. You do not insert or edit the macros again.
• What the macro shows. A published model of Flower BPM for Jira (Connect or Forge version), or a BPMN file attached to the page.

What changes

• A new macro dialog. Editing the macro opens a dialog in the look of Confluence: choose a Flower process or an attached BPMN file, then Save.
• Your language. The macro speaks the language of your Atlassian profile, like Flower for Jira: English, German, Spanish, French, Italian, Portuguese, Japanese, Chinese, Korean, Dutch, Polish, Russian and Turkish.
• No links in the navigation. The Connect version added two links Flower BPM for Jira to the navigation of Confluence. They are gone: open Flower in Jira directly.
• Runs on Atlassian. The app has no server of its own anymore. It reads the models from Jira and the files from Confluence directly, as the user who looks at the page.

What you need to do

1. A Confluence administrator opens Apps > Manage apps and updates Flower for Confluence (new sites install it from the Atlassian Marketplace ).
2. Atlassian shows the screen to approve the permissions. They are new because the app now reads Jira itself: read access to Jira (the models of Flower) and read access to the content of Confluence. The read access to the whole content of Confluence is for a feature that follows: finding BPMN, draw.io and Gliffy diagrams in your spaces. It is part of this update, so that you only approve once.
3. Jira on the same site: to show the models of Flower for Jira, the app also needs to be installed in Jira. If the installation offers Jira, select it. Without it, the macro shows BPMN files attached to the page, and a hint instead of a model: Flower for Confluence is not installed in Jira. In this case, write to support  and we help.
4. The first time a user opens a page with the macro, Atlassian may ask them to allow access to Jira for the app. This is the standard Atlassian screen.

Usage analytics (anonymous: the site as an id of Atlassian, whether a macro shows a model or a file, no names, accounts, titles or content) can be switched off by an administrator in the Analytics settings of the app in Atlassian administration.

Frequently asked questions

Do I lose anything during the update? No. The data is in Jira and is not touched. The update replaces the app, it does not delete anything.

Is there downtime? Flower may be unavailable for a few minutes while the new version is installed. Running processes continue afterwards.

What happens to a process that is running while I update? It continues after the update. Timers keep their due dates.

Who has to do the update? A Jira administrator of your site.

What if I have an evaluation or an app that is installed but not used? Nothing happens on its own. The update is offered like any other, and the evaluation continues after it.

Does the update change my users or their permissions? No. Flower works with the permissions Jira gives your users.

Does Flower send data to other companies? Usage analytics (anonymous, without names, accounts, titles or content) can be switched off in the Flower settings, tab Analytics.

I use the Flower REST API. Do I need to change anything? Check the permissions of your API user, see Flower REST API below.

Can I go back? Rolling back to the Connect version is not possible by yourself. If you have a problem after the update, contact us (see below) and we help.

My process calls a webhook URL from a throw event. Does it still work? Not in the Forge version, it cannot send data to other servers. Switch the event to Jira Automation, see Throw Events with a Webhook URL.

Where do I get help? Write to support . We are glad to do the update together with you.

Timeline