How to Inventory and Baseline Identity Action Volume in 2026

To baseline identity action volume, you do four things in order. Define what counts as one action. Pull counts from the four systems that actually record them — service desk tickets, IGA request logs, directory and identity provider events, and the HR feed. De-duplicate the same real-world action where it appears in more than one of those sources. Then roll the reconciled result into twelve trailing months, with the gaps documented rather than hidden. The output is a count per action type with a stated method behind it, and that artefact is what lets you walk into a budget meeting with a number you can defend.

It is a strangely unwritten piece of work. The industry has spent two years talking about identity in terms of actions and outcomes rather than seats, and that conversation is well covered from the concept side and the buying side. What almost nobody has written down is the counting problem underneath it: the unglamorous, entirely tractable exercise of establishing how much identity work your organization actually does. Every per-action discussion — planning, staffing, capacity, automation scope, vendor evaluation — assumes a volume figure exists. In most organizations it does not, and what gets used instead is someone's recollection, a ticket count from one queue, or a number borrowed from a conference slide.

This is deliberately a method rather than a benchmark. There is no credible "typical" enterprise identity action volume, and anyone quoting one is describing a different estate with different automation coverage and a different definition of what they counted. Your number is a property of your environment. The work is bounded — a few weeks of extraction and reconciliation, not a program — and once the method is written down, refreshing it each quarter is nearly free.

The number everyone assumes you have

Watch what happens in a planning conversation about identity. Someone proposes that a category of work be handled differently, and the first question is how much of it there is. The room turns to whoever runs identity operations, and what comes back is usually a ticket count: the password reset tickets the service desk closed last year. It is a real number from a real system, and it is almost always a severe undercount, because it captures only the resets that required a human. Every reset completed through self-service, handled by an automated workflow, or made through a channel that opens no ticket is missing. The number being planned against is not the volume of identity work; it is the volume of identity work that failed to be automated.

The opposite error is just as common. Someone pulls directory events instead and reports a figure so large it is obviously meaningless. Directory and identity provider logs record every write, every read, every token refresh, every service account poll. Without a definition of what constitutes an action, that log is a firehose of activity, not a measure of work. Both failures share a root cause: nobody wrote down what they were counting before they started counting.

The third failure is the most expensive. An organization pulls counts from several systems, totals them, and reports the sum. The sum is inflated — potentially by a multiple, for action types that flow through governed request paths — because one real-world event left a trace in three different logs and was counted three times. A baseline wrong in this direction does more damage than one that is merely incomplete, because it looks rigorous: it came from multiple systems, it has a methodology slide, and it will size a decision against work that does not exist. Capacity sized on a bad figure produces either a service desk that drowns or a team staffed for work it never sees.

Define the unit before you count anything

The highest-leverage decision in this exercise is the definition of the unit, and it has to be made before any data is pulled. Everything downstream depends on it, and a unit renegotiated halfway through invalidates the work already done.

The definition that holds up is: one identity, one completed outcome, one decision point. Each clause does work. One identity means an action performed on a single identity; a bulk operation touching four hundred accounts is four hundred actions, not one, because the work and the risk scale with the identities affected rather than with the operator's effort. One completed outcome means the action finished and produced a result; a reset the user abandoned is not an action, and three retries within the same session are one action, not three. One decision point covers the governance side: an access request is counted when it is decided, and a denial counts exactly as much as an approval, because the review consumed the same effort.

The unit is the first decision and the one that silently invalidates every number downstream if you skip it.

Two exclusions belong in the definition explicitly, because they are what people argue about later. The first is configuration work: editing a role definition, changing a password policy, building an approval workflow. That is engineering effort applied to the identity system, not an identity outcome delivered to an identity, and folding it in makes the baseline incoherent. The second is raw telemetry: authentications, session refreshes, directory reads, API polls. These measure activity, not work, and if you let them in they will swamp every other action type by orders of magnitude.

Write the definition down in a paragraph, circulate it, and get agreement from whoever will eventually consume the number — before the first query runs. Articulating it surfaces the disagreements that would otherwise appear when the finished baseline is already on a slide.

Where the counts actually live

Four systems hold identity action records. Each sees a different slice, and each one's blind spot is precisely where another one's record lives, which is why a baseline built from a single source is wrong by construction rather than merely imprecise.

Service desk tickets record what a human asked another human for: resets, unlocks, lockout calls, "I cannot get into the application." The strength is intent — a ticket usually says what the person wanted and why, which no other system carries. The weakness is coverage. Tickets see only work that failed to be self-served or automated, so the healthier your self-service adoption, the smaller the fraction of true volume this source captures. Category structure is also unreliable: the ticket taxonomy rarely matches your action taxonomy, so budget real time for mapping and sampling rather than trusting the category field.

IGA request logs record governed requests and the decisions on them: access requests, approvals, denials, certification outcomes, revocations. This is the cleanest source structurally, because an IGA platform was built to produce exactly this record. The blind spot is access granted outside the tool — the direct group change an administrator made because the request path was slow, the entitlement provisioned during an application onboarding project, the access inherited through a nested group nobody has reviewed. The rigour that makes these records trustworthy is the same rigour described in the access review an auditor actually wants.

Directory and identity provider events are the authoritative record of what actually landed: account creates, enables, disables, deletes, password changes, group membership writes. If the action had an effect on the estate, it is here. The blind spot is interpretive: the directory knows what changed and which service account changed it, but not why or who asked, so it cannot distinguish a governed grant from an unreviewed one and has to be joined to the request-side sources.

The HR feed records the lifecycle events that should drive much of everything else: hires, transfers, terminations, contract starts and ends. It is the smallest source by volume and often the most reliable, and it gives a useful validation check: if your joiner count from the directory diverges sharply from the hire count in the feed, you have either orphaned provisioning or a gap in the feed. How tightly these events translate into downstream work is covered in automated user provisioning on the joiner side and automated deprovisioning and offboarding on the leaver side.

Pull from all four, not the one that is easiest to query — each system's blind spot is exactly where another one's record lives.

Check for a fifth source: the conversational and assistant channels through which identity requests increasingly arrive. Where requests are handled in chat or through an assistant, the volume may never reach the ticketing system at all — one of the ways modern self-service erases itself from the traditional count, as AI service desk automation describes.

De-duplicating one action across three logs

Here is the step that separates a baseline from a sum, and the one most often skipped. A single real-world identity action routinely leaves traces in three systems at once. An analyst needs access to a finance reporting group. They open a ticket. The ticket drives an IGA request, which is approved and fulfilled. Fulfilment produces a directory event adding them to the group. Three records, three timestamps, three systems — one action. Total the sources naively and you have tripled it.

The correlation rule that works is a four-part match: identity, action type, target, and time window. Identity and action type are straightforward once the taxonomies are mapped. The target — which group, which application, which account — is what distinguishes two legitimately separate grants to the same person on the same day. The time window is the judgement call, and it has to absorb the real lag between request and fulfilment. Approval queues sit overnight; provisioning runs on a schedule. A few hours is too narrow for most governed paths, while a window measured in days starts merging genuinely distinct actions. Begin around a business day or two, inspect what the rule merges, and tune by looking at the merges rather than theorizing about them.

Three log lines, one real action. Correlate before you total, or the baseline you defend will be a multiple of the truth.

Once a cluster is identified as one action, pick a canonical record. The fulfilment event — the directory write, the completed reset, the applied change — is the right default, because it proves the work actually finished. Requests approved but never fulfilled are a different category; they are not completed actions, and a large population of them is a finding rather than a rounding error.

Do not delete the duplicates. Keep them linked to the canonical event, because the overlap pattern between sources is the most valuable byproduct of the exercise. An action type whose records appear in all three systems is fully governed and fully observable. One where directory events routinely have no corresponding request record tells you work is happening outside the governed path — a governance finding worth more than the count itself, and exactly the visibility gap that access governance for modern identity security exists to close.

What a defensible twelve-month baseline looks like

Twelve trailing months is the right window, because identity volume is not flat. Hiring waves, fiscal and academic year boundaries, open enrollment, certification campaigns, holiday coverage and post-holiday password expiry clusters all produce months that look nothing like the mean. Twelve months absorbs the cycles and lets you report both an annual total and a monthly distribution, which matters because capacity has to be sized against the peak rather than the average.

A baseline that holds up has five properties. It states the unit definition verbatim. It names the sources and extraction window for each one, including the query or report used. It states the correlation rules applied during de-duplication, including the time window and the canonical-record choice. It documents known gaps explicitly — systems not covered, periods where logging was incomplete, action types where the data was too poor to use. And it reports a range with a stated basis rather than a point estimate.

That last property is counterintuitive but decisive. A precise-looking figure invites the question of where it came from, and if the answer is thin the whole baseline collapses in a single exchange. A number presented as a range, with method and gaps attached, survives that question — and surviving the question is the entire purpose of the artefact.

Report the breakdown by action type, not only in aggregate. A single total is nearly useless for planning, because the types behave differently: some high-volume and uniform, some low-volume and labour-intensive, some concentrated in a handful of weeks.

The volume you cannot see

Every real baseline has holes, and the discipline is to document them rather than let them quietly become zeros. Several are predictable enough to look for deliberately.

Work handled informally. Requests made to an administrator in a hallway or a chat message that produced a real change with no ticket and no request record. The directory event exists; the request side does not. These surface as unmatched fulfilment events during de-duplication, and the size of that unmatched population is a reasonable proxy for how much informal work is happening.

Systems outside the governed estate. Applications with their own local user stores, acquired business units not yet integrated, legacy platforms with no usable audit export. Identity work happens in these and none of it is in your sources. List them by name rather than pretending the estate is uniform.

Logging windows shorter than your baseline. Retention routinely sits at ninety days or six months, shorter than the window you need. Where a source cannot cover twelve months, say so and report what it does cover. A stated short window is defensible; an annualized extrapolation presented as a measurement is not.

Synthetic and service traffic. Monitoring accounts, test identities, automation service principals and load-testing artifacts all produce records that look like identity actions, and they distort low-volume types badly. Identify, exclude, and note the exclusion.

The right posture toward all of these is disclosure rather than estimation. An estimate inserted to fill a hole becomes indistinguishable from a measurement within about two weeks of the baseline being circulated. A documented gap stays a documented gap.

What Avatier ships toward this pattern

The structural problem described here — one real-world action scattered across several logs with no common record — is an artefact of identity work being performed by many systems that each keep their own books. Where identity actions execute through a single governed layer, the record is produced once at the point the work happens rather than reconstructed afterwards from three partial accounts.

That is the shape of what Avatier ships. Avatier Actions, the MCP connector available through Avatier Identity Anywhere 2027™, exposes more than fifty identity outcomes across eight modules — Password Management, Help Desk, Lifecycle Management, User Management, Group Management, Access Governance, Workflow Approval and Reports. Because each outcome is a discrete, named capability invocation rather than an incidental side effect of several systems talking to each other, it is countable at the moment it completes.

Avatier Ledger holds the record. Each completed outcome is recorded with the identity involved, the initiating agent or experience, the authorization context, the policy applied, the action taken and the final result. Structurally, that record set is the merged action ledger this article describes assembling by hand: one canonical event per completed action, already carrying the request-side context directory logs lack and the fulfilment proof ticket systems lack. Requests arrive through web, mobile, Microsoft Teams, Outlook, chat, voice and MCP-compatible assistants in 34 languages, and all land in the same record — which keeps conversational channels from vanishing out of the count. Setup is one administrator connection, with permissions inherited from Microsoft Entra ID, Active Directory, Okta or Ping, and Avatier runs alongside those platforms rather than replacing them.

The assurance posture behind the record is published at the Avatier Trust Center: SOC 2 Type II audited with no exceptions noted, ISO/IEC 27001:2022 certified, PCI DSS v4.0.1 compliant, and CSA STAR Level 1 attestation, alongside NIST 800-53 Rev. 5 aligned and FedRAMP-aligned postures, signatory status on the CISA Secure-by-Design Pledge, and FIDO2-compatible authentication. For the platform, see the Avatier Identity Anywhere 2027™ preview. For the credential controls that generate much of the volume discussed here, see Credential Governance™ and its six pillars; for verification when a phone is not available, see the Identity Challenge Card™. Company background is at avatier.com.

What a baseline does not settle

A baseline is a measurement, and measurements are modest things. Being precise about what it does not give you is how the method keeps the credibility it earned.

It does not tell you what should be automated. Volume is an input to that decision, not the decision. A high-volume action type may be a poor automation candidate because it requires judgement that cannot be delegated, and a low-volume type may be an excellent one. Counting tells you how much; it says nothing about which.

It does not predict next year. A trailing baseline describes what happened under last year's headcount, application estate and automation coverage. An acquisition, a hiring freeze, a major application onboarding or a shift in self-service adoption will move the number materially. Treat it as the starting point for a forecast, not as one.

It does not fix the underlying data quality. If ticket categories are unreliable, the mapping you built around them is a workaround, not a repair. The baseline will have surfaced exactly which taxonomies and feeds are weak, and that list is arguably more valuable than the count — but acting on it is separate work.

It does not stay true. A baseline is accurate the day it is produced and decays steadily afterwards. Give it a named owner and a refresh cadence, quarterly in most environments, and keep the extraction queries and correlation rules in version control so a refresh is a rerun rather than a rebuild. A baseline nobody maintains becomes a number people quote long after it stopped describing anything.

What it does give you is the thing that was missing: a number with a method attached, broken out by action type, bounded by stated gaps, covering a window long enough to mean something. That is enough to plan against, enough to staff against, and enough to defend when someone asks where it came from. Every conversation about identity measured in actions assumes that artefact already exists. Now you can be the one who actually built it.