Case Study · Access Governance
Reframing scattered access requests into governed, traceable, and audit-ready workflows across the Atlassian stack.
Access decisions were happening outside governed systems. Temporary access never ended, offboarding missed a tool here and there, and nobody could answer who currently held what.
A lifecycle model and a three-horizon roadmap that aligned product, engineering, and business before a single screen was drawn. The direction shipped as a live access-governance listing.
The direction shipped: live on the Atlassian MarketplaceThis project started before UI.
Access governance was breaking down in growing teams: too many request channels, informal approvals, temporary access that never ended, and audit trails written after the risk. My role was to study the real-world access patterns, map the product ecosystem, and shape the direction before base UI.
Confidentiality note
Under NDA, so no live product screens, customer names, internal workflows, or account-level data. What follows is research synthesis, abstracted product models, and the decisions that shaped the direction.
Context
Access was not failing for lack of tools. Decisions were happening outside governed systems, while the crown-jewel systems (AWS, GitHub, Jira, Confluence, Drive) held the code, strategy, and IP.
The risk was not only unauthorized access. The bigger problem was invisible access.
Broad access granted to unblock an urgent fix stays active, because there is no expiry, no ownership, and no follow-up trigger.
An employee leaves, IT disables most accounts, one tool is missed, and no one notices for weeks.
Elevated access granted while a lead is unavailable stays active indefinitely, because no one owns the cleanup.
Across the scenarios, the pattern was the same
The scenario below runs one of them, with and without governance, so the risk is impossible to miss.
The payment is valid. The employee is trusted. The work is completed. The risk begins when temporary access has no expiry, no review, and no clear owner.
Risk level
Step 1 of 5
Operations Manager
The vendor needs payment tonight. The event setup depends on it.
The request is urgent and legitimate.
The payment was never the risk. The risk was temporary access without an end state.
Why
Access governance is an operational problem, not a screen problem.
Forms, dashboards, and approval screens were the fast start, but captured requests alone become another ticketing layer. The reframe started from evidence: how access actually fails in practice, support and offboarding patterns, dormant and over-privileged access, and conversations with the people who live in these workflows.
Before: the status-quo option
Build JSM forms where users can request app access.
After: the direction we chose
Turn every access request into a governed lifecycle that can be requested, approved, provisioned, expired, reviewed, and audited.
The core lifecycle: the central product model
Platform bet
Teams already trust JSM for requests, ownership, approvals, and SLAs, so familiar behavior could become the entry point. The opportunity: turn JSM from request intake into a governance layer.
Users already understand tickets, request forms, status updates, and approvals.
Every request can have an owner, approver, timestamp, reason, and resolution path.
Requests become traceable history instead of being reconstructed later from chats and emails.
Making the case
Governance is an easy thing to nod along to and a hard thing to fund. Every time the argument stalled, it was because people were picturing a different failure. These comparisons ended that.
A spare key handed to a neighbour before a long trip. You come back, life resumes, and nobody thinks about the key again. It is not a trust problem. It is that no moment ever arrives that forces anyone to ask the question.
So the product had to
Decide the end date when access is given, not as a cleanup task afterwards. Anything that relies on someone remembering later is not a control, it is a hope.
A building where every pass opens every door and no register is kept. Nothing has gone wrong yet. The real problem is that if something does, nobody can say who was inside.
So the product had to
Make the product answer what people currently hold, not just whether a new request should be approved. Invisible access turned out to be a larger risk than unauthorised access.
The board below is the platform mind map, nine branches and roughly seventy nodes, as a live canvas. Pick a branch, or drag and zoom the board itself.
Nine platform branches · click one to spotlight it on the board and read the thinking below
identity-access-governance-mapFigJam board
Identity & Access Governance
The request layer that turns scattered access asks into structured, owned, trackable workflows.
Ownership
The work I personally owned was the thinking before the screen: research synthesis, product strategy, workflow mapping, information architecture, and base UI planning. Product, engineering, and business stakeholders brought the domain constraints, and I turned that raw material into a direction the team could build against.
Shifted the conversation from JSM request forms to a full access lifecycle: request, approve, provision, expire, audit.
Mapped real-world failures like forgotten access and offboarding gaps into clear product decisions.
Defined the product around requests, approvals, access overview, audit, automation, insights, and integrations.
Structure
Nine branches and roughly seventy nodes need one organising rule, or the map becomes a list. This is the rule that decided every placement.
Where things live
One rule decided every placement: organise around the life of an access grant, not around the teams who happen to touch it.
Whoever is blocked
Why here
This is the only part of the lifecycle anyone actually wants to do. Everything downstream is the bill for it, so this step has to stay cheap or people route around it.
The people accountable
Why here
This is where governance actually lives, and in the research it had no home anywhere. Invisible standing access was a bigger risk than unauthorised access ever was.
Usually nobody, which was the problem
Why here
Every failure pattern in the research lived here, and every one of them was somebody's forgotten task. Anything that depends on remembering had to become automatic.
The journey
Four moments, and nobody in them is behaving badly. That was the finding that changed the product: every failure pattern in the research came from reasonable people at a moment where nothing prompted them.
The journey, in plain words
4 stages
“I will just ask in the channel. Someone with rights will sort it out in five minutes.”
What the design does
Keep the fast path fast, but make it produce a record. The request happens either way, so the design question is only whether anything survives it.
“I am not completely sure what this opens up, but they are blocked and I trust them.”
What the design does
Show what the grant actually reaches at the moment of approval, rather than in a policy document nobody opens.
Held back
This stage shaped the design but sits too close to the product to show. Happy to walk through it in conversation.
“Nothing. Nobody thinks anything at this point, and that is precisely the problem.”
What the design does
Make expiry a property of the grant, decided when access is given. Removal then needs nobody to remember it.
No villain anywhere in this journey. Governance that assumes one will always lose to governance that assumes nobody remembers.
Alignment
JSM request forms were shippable in weeks. A governed lifecycle was not, and the pressure to take the fast start was legitimate.
How it resolved
I showed where forms end up: captured requests with no expiry and no owner become another ticketing layer on top of the problem, which is the exact failure the research had already documented.
A lifecycle that reaches across the whole Atlassian stack is an order of magnitude beyond request intake.
How it resolved
Three horizons, with a core foundation small enough to build first. The lifecycle was the direction, not the first release.
This read as an internal convenience tool rather than something with a market.
How it resolved
I reframed it as access governance for the Atlassian stack rather than an approval form inside JSM. That is a category with buyers, and it changed which questions the roadmap had to answer.
Base UI direction
Shown here as a white-labeled recreation of the Visual Rule Builder, the flagship of the Governance Automation branch: a repeated access pattern becomes a reusable rule that reads context, routes approvals, then provisions, expires, and logs automatically.
Flip the request risk to watch the approval chain adapt, then activate the rule.
Who it serves
One access decision passes through six people, each accountable for a different part of the lifecycle.
Job to serve
Get the access they need to do the job quickly, without guessing what to ask for or chasing approvals.
Job to serve
Approve or deny with enough context to be accountable, and not become the bottleneck.
Job to serve
Provision and de-provision reliably across the stack, and keep the system of record clean.
Job to serve
See high-privilege, dormant, and over-privileged access, and act before it becomes risk.
Job to serve
Prove who has access to what, and why, without reconstructing it from memory at audit time.
Job to serve
Control who reaches their app and for how long, with expiry and revocation built in.
The service, end to end
| Stage | Request | Approve | Provision | Expiry / revoke | Audit |
|---|---|---|---|---|---|
| User action | Requests access to an app or role | Sees the decision | Access appears | Access ends or is pulled | - |
| Frontstage (product) | Guided request in JSM | Approval with rationale | Provisioning confirmation | Expiry countdown and revoke action | Access-review surface |
Line of visibility | |||||
| Approval workflow | Routes by risk | Records who approved and why | Triggers provisioning | Triggers cleanup | - |
| Governance record | Logs the request | Logs the decision | Logs the grant | Logs the revocation | Answers: who has access now, and can we prove it |
Impact
The value was alignment before execution: access governance reframed from a set of screens into a platform model with lifecycle logic and roadmap depth.
Research, scenarios, and the platform mind map created shared understanding across product, engineering, and business.
Framed the work as access governance for the Atlassian stack, not another approval form inside JSM.
Separated core v1 needs from intelligent enhancements and future governance maturity.
What I would measure
Signal typeMeasuredObservedIntendedFuture
A lifecycle model, a nine-branch platform map, and a three-horizon roadmap were produced and used to align product, engineering, and business.
The design aims to stop temporary access becoming permanent by making expiry and revocation first-class flows.
Every request captures who asked, who approved, why, and when it ends, so audit prep no longer depends on memory and spreadsheets.
Share of expired or flagged access actually removed, and how quickly.
Sequenced across three horizons
The access-review surface below is where the Home, Access Overview, and Audit branches converge. Switch across the lenses that admins, managers, and auditors each rely on.
How admins and auditors review access without rebuilding history manually. Switch across the access-review lenses, high-privilege, expiring, dormant, and personal, team, and org scopes, that admins, managers, and auditors each rely on.
Elevated access across the org, with age, ownership, and expiry status, reviewable before anyone asks for proof.
Platform engineer
AWS admin · 214 days
No expiry · review
ReviewRelease manager
GitHub org admin · 97 days
Expiring in 12 days
ReviewContractor
Jira site admin · 41 days
No expiry · review
ReviewAudits should not feel like fire drills. The product needed to make access history visible before someone asked for proof.
Judgment
The research moved stakeholder discussions from isolated feature requests to product principles: a governance lifecycle, not a form builder, native to the Atlassian stack rather than a disconnected IAM console.
The calls we aligned on are below as a decision board. Pick a side on each one and watch the direction change.
Each pair below is a real trade-off from the stakeholder alignment phase. Pick a side on every call and watch what kind of product you end up with.
Identity & Access Governance via JSM
Direction review · product, engineering, business, design
Request layer
Employee experience
Access end state
V1 scope
The product you end up with0 of 4 aligned
This is the status quo the research documented: ad-hoc decisions, manual revocation, reactive audits. Access goes invisible after approval.
Alignment before execution: the team agreed on a governance lifecycle, not a form builder, before any base UI.
Reflection
Governance products fail when they only capture requests. The real value comes after approval: provisioning, expiry, review, cleanup, and proof.
The UI came later. The real design work started with making the problem impossible to misunderstand.
Next Project
SecureShare for Confluence →