We’re rolling out a policy requiring manager and QA lead sign-off before closing any Sev-1 defect. I’m debating whether to add custom approval fields (Approved By, Approval Date) or introduce intermediate statuses like ‘Pending Manager Approval’ and ‘Pending QA Lead Approval’.
Another angle: how do you enforce role-based conditions on the transition to Closed? We need an audit trail showing who approved and when. Some teams mentioned marketplace apps, but I’d prefer built-in capabilities if possible.
Curious how others balance workflow simplicity with audit requirements and whether extra statuses become unwieldy as approval chains grow.
One gotcha: if you use custom fields for approvals, make sure they’re mandatory on the Close transition. Otherwise someone can bypass the approval by directly closing the issue. We learned that the hard way during an audit. Also, consider a post-function that stamps the approver’s username and timestamp into a read-only field so it can’t be tampered with later.
We started with custom fields-two dropdowns for Manager Approval and QA Approval, plus date stamps. It kept the workflow lean, but reporting became a nightmare. Filtering on ‘approved by X’ required JQL gymnastics. Eventually we moved to statuses because the board columns made approval bottlenecks visible instantly.
After experimenting with all these approaches, here’s what works best for audit-heavy environments:
Custom Fields vs Statuses: Use custom fields for who approved (Manager Approver, QA Lead Approver) and when (Approval Date). Reserve statuses for where the defect is in the pipeline. This separation keeps your board readable while preserving audit data. Create a ‘Pending Approval’ status, but don’t subdivide it further.
Role-Based Conditions: Set up transition screens with validators that check group membership. For the Manager Approval field, add a validator requiring the current user to be in ‘DefectManagers’. Do the same for QA leads. This enforces that only authorized users can populate approval fields.
Audit Logging: Enable issue history and use a post-function on the approval transition to add a comment like ‘Approved by {currentUser} on {currentDateTime}’. This creates an immutable record in the activity stream. For quarterly audits, export the changelog via REST API and parse approval events.
Marketplace Apps: If built-in features feel limiting, look at apps like Approval Path or ProForma. They add visual approval flows and can send email notifications when approval is needed. But honestly, a well-configured automation rule can replicate most of that functionality.
Key Trade-Off: Extra statuses give you Kanban visibility but clutter the board. Custom fields give you audit granularity but hide approval state unless you add board swimlanes or labels. We ended up with one ‘Pending Approval’ status, two custom fields (manager/QA approver), and automation rules that comment when each approval is granted. Board stays clean, audit trail is solid, and we can report on approval bottlenecks using JQL filters on the custom fields.
If your approval chain has more than three levels, seriously consider a dedicated approval app-managing that many validators and fields manually becomes brittle.
We tried the intermediate status approach and it got messy fast. Five approval levels meant five new statuses, and our board became unreadable. Switched to a hybrid: one ‘Pending Approval’ status plus a custom multi-select field listing required approvers. As each person approves, they remove their name from the field. When it’s empty, the issue auto-transitions to Closed. Keeps the board clean and gives you granular audit data in the field history.