Permission Handling

Flower does not introduce a new permission model — instead, it builds entirely on Jira’s proven permission system.
This ensures that your existing Jira security setup continues to work seamlessly, without adding complexity.

Built on Jira Permissions

Jira manages access through projects, issue types, and issues.
Since Flower is deeply integrated into Jira, it reuses this structure directly:

Models, Process Instances, and Tasks in Flower are all represented as Jira issues.
Each of these entities belongs to a Jira project and uses a defined issue type.
As a result, all access control — including visibility, editing, and workflow permissions — is managed by Jira itself.

Organizing Models

To separate and secure your process models, simply organize them into different Jira projects.
Flower automatically inherits the permission schemes and roles from the corresponding Jira projects.

When creating or importing a new model, you can select the Jira Project and Issue Type under the Advanced Options in the Create Model dialog.
This determines where the model issue is stored and which Jira permissions apply.
As a result, the model immediately inherits all security rules of the chosen project and issue type — no extra setup required.

Create Flower Model

The Flower Repository page only displays models that the currently logged-in user has read access to according to Jira’s permission settings.
Users will never see or access process models they are not allowed to view in Jira.

Process Instances and BPMN Activities

When you start an automation, Flower creates a Process Instance in the Jira project specified in the model configuration.
The same logic applies to all BPMN activities defined in the process — each task is created as a Jira issue within the appropriate project.

This design allows you to build and automate processes that span multiple departments or permission groups while maintaining Jira’s access boundaries.
Each process participant only sees and interacts with the content they have permission to access.

Example

Let’s look at a simple example that includes all three Flower entity types — Model, Process Instance, and Tasks:

Model
You create a model called Onboarding Process and store it in the Jira project HR.
Only users with access to the HR project can view or edit this model in the Flower Repository.
Process Instance
When HR starts the onboarding for a new employee, Flower automatically creates a Process Instance issue in the HR project (or in another target project defined in the model).
The permissions of this instance are identical to those in Jira — only users who have access to the HR project can open or interact with it.
Tasks
The BPMN process contains several activities such as:

“Create IT Account” → created as a task in the IT project
“Prepare Workspace” → created as a task in the Facilities project
“Collect Documents” → created as a task in the HR project

Each task inherits the permission scheme of its Jira project.
This means IT staff only see and complete IT-related issues, Facilities only see their workspace setup task, and HR retains access to the full process overview.

This structure allows Flower to orchestrate cross-departmental workflows while respecting each team’s existing Jira permissions.

How Permissions Affect Typical Actions

Browsing the Repository – Users only see models in projects where they have permission to browse issues.
Starting a Process – The user must have permission to create the Process Instance issue in the target project and issue type. Jira’s create permissions and validators apply.
Working on Tasks – Only users with permissions on the task’s Jira issue can view or transition it. Workflow conditions, validators, assignee, and roles apply as usual.
Cross-project Processes – Participants gain access only to the issues created in the projects where they already hold permissions. Flower never broadens or overrides Jira access.

Best Practices

Use clear project boundaries – Mirror your organization with distinct Jira projects and permission schemes per department or business unit.
Separate environments – Consider separate Jira projects (or instances) for sandbox and production models to control who can see or run them.
Minimal privileges – Grant only the roles and permissions necessary for each group to execute their steps.
Reuse issue types wisely – Create dedicated issue types for Flower entities where needed to simplify permissions, screens, and workflows.
Audit with Jira tools – Use Jira’s logs, Permission Helper, and workflow conditions/validators to understand or refine access.

Global Settings and Defaults

In the Flower Settings section (accessible only to Jira Global Administrators), you can define default Jira projects and issue types for each Flower entity type:

Default Project and Issue Type for Models
Default Project and Issue Type for Process Instances
Default Project and Issue Type for Tasks

These defaults provide a consistent setup across your organization while still allowing flexibility per process model.

FAQ

Does Flower bypass Jira permissions?
No. Flower never bypasses Jira. If Jira denies access, Flower denies access.

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 underlying Jira project and issue type.
Use Jira’s Permission Helper to diagnose access issues.

Learn More

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 mature permission system, Flower ensures security, transparency, and compatibility — without introducing new configuration overhead.