Zluri's governance intelligence dashboards surface the health of your identity governance program from the same data layer that runs it: every access request, review decision, workflow execution, and account state, measured live. This is the walkthrough: how the dashboards work, what each one covers, and the metrics available in each view.
Identity governance produces an enormous amount of operational data. Every access request carries a decision, a timestamp, and a policy trail. Every review campaign produces keep-or-revoke outcomes per entitlement. Every offboarding workflow either completes or fails, step by step, app by app. In most identity stacks, that data is scattered across tools and effectively unreportable without a dedicated BI project.
Zluri's governance intelligence dashboards exist because in Zluri, none of that data is scattered. Discovery, access requests, reviews, and workflow automation run on one platform, which means the platform can measure the entire governance chain as a byproduct of operating it. The dashboards are the reporting surface on top of that data layer, and they exist to make one promise concrete: we don't just tell you governance is strong, we show it.
This article is the mechanics tour: how the dashboards work and what's in each one. For the reasoning behind which metrics matter and what healthy values look like, the companion guide on how to measure an IGA program owns that ground.
How the Dashboards Work
The dashboards read directly from the same records Zluri creates while doing its normal work: request objects, certification decisions, workflow executions, and per-app account state from Zluri's discovery engine. There's no export pipeline behind them and no separate identity-resolution project, because discovery has already resolved every account back to an identity.
That's also why a failed offboarding workflow shows up as a failed workflow immediately rather than in next month's report: the data is live, not a periodic snapshot. What that gap between live and exported data usually costs a program to close is covered in why disparate identity stacks can't measure themselves.
Views filter along the dimensions governance conversations actually use. Department and business unit, application, entitlement, time period, and lifecycle event type. The same underlying data answers an auditor's question ("show revocations for this app in Q2"), an ops question ("which connector keeps failing"), and a board question ("is automation coverage trending up") without three different reporting tools.
The Six Dashboards
1. Access Governance
The front door of the program: what's being requested, how decisions get made, and how fast.
The two to watch as a pair: auto-decision rate rising while policy match coverage rises means approver knowledge is being codified into rules. Auto-decisions rising while exceptions spike means policies are drifting and need review.
2. Access Reviews & Certifications
Campaign execution and, more importantly, whether reviews change anything.
The cycle-over-cycle view deserves special mention because almost no governance tooling offers it. Comparing the same recurring campaign across quarters answers the question auditors and skeptical CISOs both ask: are these reviews a control that improves things, or a ritual that finds the same problems forever?
3. Entitlement & Account Hygiene
The state of access itself, independent of any campaign.
Worth pausing on the license row: an assigned-but-unused license is usually discussed as wasted spend, but it's equally a dormant access right that survived its own usefulness. The hygiene dashboard shows both dimensions of the same fact, which is why finance and security end up looking at the same view for different reasons. The entitlement-popularity view pairs naturally with it: an entitlement that's both widely held and frequently revoked is a role-design problem hiding behind a hygiene metric.
4. Lifecycle Automation
The reliability layer: whether joiner, mover, and leaver automation actually completes.
This dashboard embodies a distinction that matters more than any single number on it: Zluri tracks workflow completion, not just initiation. A triggered workflow that failed at step four of nine is displayed as exactly that, with the failing step identified. Automation you can't verify is automation you can't trust, and this is where the verification lives.
5. Application Governance
The estate view: how much of your application landscape is under real control.
Ownership is the quiet one here. An app without an owner has no one accountable for its reviews, its provisioning policy, or its lifecycle automation, and everything else on this dashboard degrades from that gap. The ownership view makes it a countable, assignable problem.
6. Audit & Compliance
The evidence layer: proving governance happened and worked.
The exception registry reflects a specific philosophy about audits: the goal is not zero exceptions, which no real environment achieves, but demonstrated control over every deviation. Time-bound, owned, and visibly aging beats theoretically absent. Auditors have seen enough spreadsheet-tracked exceptions to know the difference on sight. Where the Reviews & Certifications dashboard tracks exceptions as they come out of a specific campaign, this view rolls them up across every source of governance activity, which is the level auditors actually ask about.
What Teams Actually Do With These
Audit preparation compresses from weeks to a working session. The evidence auditors request, review completion, enforcement proof, exception handling, offboarding timeliness, is the standing content of dashboards rather than an assembly project. Several views map one-to-one onto standard audit requests.
Operations gets a remediation queue instead of a mystery. Pending-offboarded-users-with-active-accounts and workflow failure analysis are directly actionable lists: this account, this app, this failed step. The distance between seeing a problem and fixing it is a workflow trigger away, on the same platform.
Leadership reporting gets real numbers. Automation coverage trending up, MTR trending down, certification coverage by department: these travel into QBRs and board decks without translation, because they're outcome metrics rather than tool telemetry.
Frequently Asked Questions
Do the dashboards require a separate BI tool or data warehouse? No. They read directly from Zluri's live governance data: the requests, review decisions, workflow executions, and account states the platform records while operating. There's no export pipeline to build or maintain, and no separate identity-resolution work, since discovery already maps every account to an identity.
Is the data in the dashboards updated in real time? The dashboards reflect operational state as governance happens, not periodic snapshots. Workflow failures, new exceptions, and completed revocations appear as they occur, which is what makes views like the pending-offboarded-users queue usable for active remediation rather than retrospective reporting.
Can metrics be filtered by department or business unit? Yes. Department, business unit, application, entitlement, lifecycle event type, and time period are standard dimensions across the dashboards, so the same data serves auditor-level, ops-level, and executive-level questions.
Which metrics matter most for an audit? Certification coverage score, revocations by application (evidence that reviews produce enforcement), the exception registry with aging, and Mean Time to Revoke cover the core of what auditors ask about identity governance. The audit and compliance dashboard groups these deliberately.
Do these dashboards cover non-human identities as well? Zluri governs non-human identities, service accounts, tokens, and AI agents, through the same discovery, review, and workflow engine as human identities, so governance activity involving them flows through the same underlying data. Hygiene signals like dormancy and orphaned accounts are particularly relevant for non-human identities, which rarely have anyone watching them by default.
.svg)
