Case Study · Access Governance
Reframing scattered access requests into governed, traceable, and audit-ready workflows across the Atlassian stack.
This 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.
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.
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 →