Self-service Jira administration, with approval and an audit trail.

What FlowOps for Jira is

FlowOps for Jira is an app that runs inside Jira Cloud. It turns “can you change this in Jira?” messages into a clear workflow: Request → Review → Approval → Execution → Verification → Audit.

Without a process, administration requests arrive by chat, email or comments on tickets. Details are missing, nobody records who approved what, and administrators repeat the same clicks. FlowOps replaces that with a form for each kind of change, a single approval queue, automatic execution for the changes Jira can safely perform through its API, and an audit log.

It is honest about what it can and cannot do. Every request type is labelled Automated, Assisted (Beta) or Request Only. Nothing is ever shown as done unless the app has read the result back from Jira, and anything the app cannot do itself becomes a clearly written task for an administrator.

Goals

• One place for every request, with status, priority, risk level, comments and history.
• Separation of duties between the person who asks and the person who approves.
• Verification: after a change, the app reads the object back from Jira and compares it with the request.
• Visibility for managers and auditors: dashboard, SLA tracking and an exportable audit log.
• Privacy by design: only account IDs are stored; names and avatars are looked up live from Jira.

Who it is for

It suits organisations that centralise Jira administration but receive requests from many teams, from a few dozen users up to large sites.

How it works

1. Choose a request type. Open New Request and pick a card. Each card shows whether it is Automated, Assisted (Beta) or Request Only.
2. Fill in the form. Pick items from lists, set a priority (Low, Medium, High or Urgent), give a reason, then review a summary before sending. If an administrator has set a limit on requests per person per 24 hours, it applies here.
3. Review and approval. The request enters Pending Approval. An approver can approve it, reject it, or ask you for more information. You are notified in the app.
4. Execution. Automated requests are executed in Jira by an administrator (one click) and the app reports every step. Assisted and Request Only requests become a task with exact instructions for an administrator.
5. Verification. The app reads the object back from Jira. If it does not match, the request is not marked complete.
6. Audit and analytics. Every decision and execution step is written to the audit log and feeds the dashboard.

Request statuses

Install and first-time setup

FlowOps for Jira is a Jira Cloud app. No server, database or external account is needed.

1. Install from the Atlassian Marketplace. A Jira administrator opens the FlowOps for Jira listing, chooses Get it now (or Try it free) and selects the Jira site. The app can also be found in Jira under Apps → Explore more apps.
2. Approve the permissions. Jira shows what the app needs: it stores its own data in Atlassian-hosted storage, reads Jira work items, users and project information, and can manage Jira configuration and projects (needed to carry out approved requests). It also contacts the Atlassian Marketplace for app search and loads avatars. Nothing is sent to Update Lab.
3. Open the app. In Jira, open the Apps menu and choose Jira Admin Request Center (the FlowOps app). Everyone on the site can open it to submit requests.
4. There is nothing to configure to start. Everyone who holds the Administer Jira permission becomes an app administrator automatically the first time they open the app. They can approve, execute, view all requests, read the audit log and change settings.
5. Optional first steps in Settings (see Settings): set the application name, time zone and default priority; set SLA hours; set how many requests one person may submit per day; give other people approver or executor capabilities; decide how long audit entries are kept.

Try it in 5 minutes

This walkthrough uses Create Priority, an Automated request that is safe to try, and needs only one Jira administrator.

1. Allow self-approval for testing. By default a person cannot approve their own request. If you are testing alone, open Settings → Approvals, tick Allow administrators to approve their own requests and press Save settings. (Turn it off again afterwards.)
2. Submit a request. Open New Request, choose Create Priority, enter a name (for example “Escalation”), pick a colour and an icon, add a reason, review and submit. The request opens with the status Pending Approval.
3. Approve and execute. Open Approval Queue, open your request, read the approval summary, and press Approve & Execute. Each step appears as it happens: validating, checking Jira permissions, creating, and reading it back to verify.
4. Confirm the result. The request shows Completed. In Jira, Settings → Issues → Priorities now lists the new priority.
5. Look at the record. Open Audit Log to see the submission, approval, execution and verification entries, and Dashboard for the request statistics.

To see the other flows, try an Assisted request such as Remove Application: after approval, Prepare manual instructions shows the exact steps for the administrator and waits for them to confirm completion.

Roles and permissions

Everyone who opens the app can submit requests and follow their own. Administrative rights come from five capabilities, checked on the server for every action:

Jira administrators (people with Administer Jira) receive a default set of capabilities automatically; Configure is always included for them. Any other person can be given individual capabilities in Settings. The app never lets the last person who can configure it be removed, so nobody can be locked out.

Requesters see only their own requests. Technical failure details are shown to administrators only.

Request types

26 request types, in five groups. Use the search box or the capability filter, and expand every card to see exactly what the form asks for and what happens after approval.

Capability labels

Approving a request

Approvers work from Approval Queue (requires the Approve and View all capabilities). The queue can be searched by ID, project or summary, filtered, and is shown 15 requests per page.

1. Open the request. You see the requester (by name), the request type, project, priority, risk level, the exact values that were submitted, comments and the timeline.
2. Read the approval summary. It shows the requester, request type, project, risk, whether it is Automated, Assisted or Request Only, and a list of potential issues (for example “this role looks administrative” or “the application name could not be verified”).
3. Decide.
   • Approve moves it to Approved so it can be executed.
   • Approve & Execute (shown when you also hold Execute and the type is Automated) approves and runs it in one step.
   • Request Information returns it to the requester with your question. A note is required.
   • Reject closes it with your explanation. A note is required.
4. Optionally assign it to yourself or another administrator.

Risk levels

Each type has a fixed risk level shown on its card and in the queue. High risk types (for example Create Project, group membership and application changes) always need a human decision.

Execution and results

Automated requests

An administrator with the Execute capability presses Execute in Jira (or Approve & Execute). The app validates the stored request again on the server, checks that the executing administrator holds the needed Jira permission, performs the change, and reads the result back from Jira. Progress is written to the request as it happens.

Assisted and Request Only requests

After approval an administrator presses Prepare manual instructions. The request shows exact steps (for example “Jira settings > Apps > Manage apps: find the app and uninstall it”). When the work is done in Jira, the administrator confirms completion and the request is closed.

Cancelling and deleting

Requesters can cancel their own request while it is still waiting. Administrators can cancel open requests. Users with Configure can permanently delete a request together with its activity and comments; the deletion itself is recorded in the audit log. Requests that are queued or executing cannot be deleted.

Settings

Settings are available to people with the Configure capability and are all recorded in the audit log.

Trusted users

For routine, low-risk requests, an administrator can mark specific people as trusted for a specific request type. When a trusted person submits that type, the app approves it automatically and executes it straight away, without waiting in the approval queue.

Where: Settings → Request types → Trusted users column. Pick a person with the user picker and choose Add trusted user; remove them with the × next to their name. Each card has its own list (for example: Alice is trusted for Create Custom Field only).

• Available only for Automated types that are not High risk. High-risk and non-automated types always go to a human.
• A request with warnings (for example one that touches an administrative-looking role) is never auto-approved.
• Each automatic approval is recorded in the audit log as AUTO_APPROVED_TRUSTED; adding and removing trusted users is recorded too.
• These requests run with the app’s own identity rather than with an administrator’s, so they can only do what the app itself is allowed to do in Jira. If an attempt fails, the request becomes Failed and an administrator can retry it.

Dashboard, SLA and audit log

Dashboard

Shows requests by type, status, project and priority, requests over time, average resolution time by type, the most requested actions, projects and users with the most requests, and automation opportunities (frequent requests that could be handled faster).

SLA and notifications

Each request gets a deadline from its priority. The app checks open requests hourly and sends an in-app notification when a request is at risk and again when it breaches. Requesters are also notified when their request is approved, rejected, needs information, completes, fails or needs manual work. Opening the Notifications page marks them read; read notifications are deleted after a week.

Audit log

Every submission, decision, execution step, settings change and permission change is appended to the audit log. Entries are chained so any tampering can be detected. People with the Audit capability can search it by request, export it as JSON or CSV, and delete entries older than a chosen number of days. An automatic clean-up deletes entries older than the retention period you set (14 days by default), so export first if you need a longer record. Each clean-up is itself recorded.

Security and privacy

• Server-side authorisation. Every action is checked on the server against the user’s capabilities, never trusted from the browser.
• Jira permissions apply. Automated changes run as the executing administrator, so Jira’s own permission model still decides what is allowed.
• Minimal personal data. Only Atlassian account IDs are stored. Names and avatars are looked up live from Jira in the user’s browser and are not stored by the app.
• Data stays on Atlassian. Data is kept in Atlassian-hosted Forge storage. The only external call is the Atlassian Marketplace search used by Install Application; if it is unreachable the form falls back to typing the name.
• Retention under your control for audit entries, finished requests and notifications, with export before deletion.
• Licensing. If the app’s licence becomes inactive, it switches to read-only: existing data stays visible but no new changes are made until the licence is renewed.