Permission Handling

Access Control for Models, Process Instances, and Tasks

Permission Handling

Flower does not introduce a new permission model. It builds entirely on Jira’s permission system, so your existing Jira security setup keeps working without extra configuration.

Built on Jira Permissions

Jira manages access through spaces, work types, and work items. Flower reuses this structure:

• Models, process instances, and tasks are all Jira work items.
• Each of them belongs to a Jira space and has a work type.
• Jira controls the access to them, including visibility, editing, and workflow permissions.

Organize Models

To separate and secure your process models, store them in different Jira spaces. Flower uses the permission schemes and roles of the space.

When you create or import a model, you can select the Jira space and the work type under Advanced Options in the Create Model dialog. This decides where the work item of the model is stored and which permissions apply. The model immediately inherits all security rules of this space and work type.

The Flower Repository shows only the models that the logged-in user can read in Jira. Users never see models they are not allowed to view in Jira.

Process Instances and Activities

When you start a process, Flower creates a process instance as a Jira work item. For each activity, Flower creates a work item in the space that you defined for the activity, for its swimlane, or in the Flower Settings. See Defining Jira Space & Work Type.

This way, you can build processes across several departments or permission groups, and Jira’s access boundaries stay in place. Each participant sees and works on the work items they have permission for.

Which User Does Flower Act As?

Two kinds of requests exist:

• Requests of users. When a user browses the repository, starts a process in the Flower app, or edits a work item, Jira checks the permissions of this user.
• Requests of the Flower engine. The engine works in the background. It creates the work items of the activities, resolves the process instance, or calls a webhook. It does this as the Flower app user, not as the user who started the process. Changes made by the engine appear in the history of a work item under the name Flower.

In Jira Cloud, Jira creates the app user when Flower is installed and adds the project role atlassian-addons-project-access to the permissions of your spaces. If you remove this role from a permission in a space, for example the permission to create work items, Flower cannot create work items there.

In Jira Data Center, the engine acts as the user that you configure in the Flower Settings, see Setup Flower.

Example

This example includes all three Flower entity types: model, process instance, and tasks.

1. Model
   You create a model called Onboarding Process and store it in the space HR.
   Only users with access to the HR space can see or edit this model in the Flower Repository.

2. Process instance
   When HR starts the onboarding for a new employee, Flower creates a process instance work item in the HR space (or in another space defined for the model).
   Only users who have access to the HR space can open it.

3. Tasks
   The BPMN process contains several activities:

   • “Create IT Account” → work item in the IT space
   • “Prepare Workspace” → work item in the Facilities space
   • “Collect Documents” → work item in the HR space

   Each work item uses the permissions of its space. IT staff only see and complete IT work items, Facilities only sees its workspace task, and HR keeps the overview of the whole process.
   The HR employee who starts the process does not need access to the IT or Facilities space for this, because the Flower app user creates these work items.

This structure allows Flower to coordinate workflows across departments while respecting the permissions of each team.

How Permissions Affect Typical Actions

• Browsing the repository: Users only see models in spaces where they can browse work items.
• Starting a process: The user needs permission to create the process instance work item in the target space with the right work type. Jira’s create permissions, required fields, and validators apply.
• Working on tasks: Only users with permissions for the work item can view or transition it. Workflow conditions, validators, assignee, and roles apply as usual.
• Processes across spaces: Participants only access the work items in spaces where they already have permissions. Flower never gives a user more access than Jira does.
• Work Type Mapping: The mapping table only shows what the current user can access. Entries for spaces or models without access are shown as no access or not available.

Best Practices

• Use clear space boundaries: Mirror your organization with separate Jira spaces and permission schemes per department or business unit.
• Separate environments: Use separate spaces (or sites) for sandbox and production models to control who can see or run them.
• Grant minimal privileges: Give each group only the roles and permissions it needs to do its steps.
• Use dedicated work types: Create dedicated work types for Flower entities where needed to simplify permissions, screens, and workflows.
• Keep the Flower app user in your spaces: In Jira Cloud, do not remove the atlassian-addons-project-access role from the permissions of spaces in which processes create work items.
• Audit with Jira tools: Use Jira’s audit log, the permission helper, and workflow conditions and validators to understand or refine access.

Global Settings and Defaults

The Flower Settings are only accessible to Jira administrators. There you define the defaults for all Flower entities:

• The default Jira space
• The default work type for models
• The default work type for process instances
• The default work type for tasks

The defaults give you a consistent setup. Where needed, models, swimlanes, and activities can override them. See Setup Flower.

FAQ

Does Flower bypass Jira permissions?
No. Users cannot see or change anything through Flower that Jira does not allow. The Flower engine works with its own app user in the background (see above), and you control its access with Jira permissions as well.

Can I define Flower-specific roles?
No. Flower uses Jira groups, roles, and permission schemes. It does not introduce a separate role system.

Why can’t a user see a model or task?
Check that the user can browse the space that contains the work item, and that no work item security level hides it. Use Jira’s permission helper to diagnose access issues.

Who is shown as the author of changes that Flower makes?
The Flower app user, shown as Flower. Changes made by users appear under their own names.

Summary

Flower’s permission concept is simple: if a user can access it in Jira, they can access it in Flower.

By relying on Jira’s permission system, Flower keeps your security setup intact and adds no new configuration.

What’s Next?

• Setup Flower: Configure the defaults for space and work types.
• User Tasks: Learn how activities become work items and where they are created.
• Users and permissions : Atlassian’s overview.
• Permission schemes in Jira tutorials : How permission schemes work.
• More about Jira permissions : Further Atlassian resources.