Provisioning request intent classifier

Most provisioning queues receive requests as unstructured sentences in a ticket description, chat message, or email body. The requester names an application inconsistently, bundles several needs into one paragraph, or references a prior approval that is not attached. A human triager reads the text, guesses which catalog item or workflow template applies, and only then forwards the ticket.

That reading step is where speed is lost. The grant itself may already be automated once the ticket lands on the right workflow. The bottleneck is routing: matching language to the correct provisioning path before any entitlement change runs.

An intent classifier addresses routing only. It reads the request text, identifies which provisioning workflow the language points to, and returns a workflow identifier plus the exact words that justified the match. It does not approve access, attach roles, or call create-user APIs. When the text does not support a defensible route, the workflow field stays empty and a person decides.

Treat each incoming request as a single document. Load the full free-text body the requester submitted, including subject lines or form fields your intake channel concatenates into one string. Strip signatures and quoted reply chains if your channel adds them, but keep the requester's original wording intact.

The classifier compares that text against your organization's workflow catalog. Each catalog entry maps to one provisioning path: new SaaS entitlement, distribution list membership, privileged elevation, contractor extension, or another template your IAM or service desk already maintains. The model output is structured and minimal:

• Workflow ID: the identifier of the target provisioning workflow, or empty when intent is unclear
• Text cite: the contiguous span from the request that supports the chosen workflow

The cite is not decoration. It is the audit trail that explains why the ticket moved. A valid result for "Please add Jordan to the Acme Corp Salesforce sandbox, same profile as last quarter's marketing contractors" might return workflow saas-salesforce-sandbox with cite add Jordan to the Acme Corp Salesforce sandbox. A triager can scan the cite in one glance and confirm the route before the workflow starts.

If the same paragraph mentions Salesforce and a VPN group, the classifier should not silently pick one workflow unless one intent clearly dominates the text. Mixed or ambiguous requests should return an empty workflow ID so a human splits or clarifies them. Speed comes from confident routes, not from filling every field.

Placement depends on where free-text enters your environment, but the pattern is the same across vendors.

Intake hook. Run classification at ticket creation or on the first transition out of "New." ServiceNow flows can call an integration step after the description field is populated. Jira automation can trigger on issue create when the issue type is "Access Request." Microsoft Entra entitlement management and Okta workflows both accept upstream signals; pass the classification result as a custom field or tag rather than as an approval decision.

Catalog alignment. Your workflow IDs must match real templates already in the tool. If the classifier returns dl-finance-announce, that ID must resolve to an existing ServiceNow catalog item, an Okta workflow bundle, a Microsoft Access Package assignment policy reference, or a Jira sub-task template your team actually runs. Build the workflow list from what operations owns today, not from a generic taxonomy.

Human checkpoint. Route classified tickets to a triage queue that shows the cite alongside the suggested workflow. The triager confirms or overrides. For high-risk paths (privileged access, production systems), keep a mandatory human approval even when the cite is clean. Classification replaces guesswork, not accountability.

Downstream handoff. Once confirmed, trigger the same automation you would have triggered after manual triage. Pair this pattern with agentic access provisioning when fulfillment itself is automated, but keep the classifier strictly upstream of any grant action.

An empty workflow ID is a correct outcome, not a failure to fix by lowering thresholds.

Leave the field blank when:

• The request names no specific resource ("I need access for the new project")
• Multiple workflows are equally plausible from the same sentences
• The text references a person or group ("same as Alex") without enough context to resolve which entitlement that implies
• Required details are missing, such as environment (prod vs sandbox) or duration
• The message is a status check or cancellation, not a new provisioning ask

Operators sometimes pressure the model to always suggest something. That produces false precision. A blank route keeps the ticket in human triage, which is faster than unwinding a wrong workflow that already fired partial grants.

Document blank outcomes in your runbook: triagers ask a standard clarifying question, split multi-intent text into child requests, or link to onboarding package auto-builder when the request is really a role-based bundle rather than a single app.

Three mistakes turn a routing aid into an access risk.

Routes without text cites. If your integration accepts a workflow ID but ignores the cite, triagers cannot verify the match quickly. Worse, automated downstream steps may fire on an unreviewed guess. Reject any classification payload that omits a cite span or points to text that does not appear in the source request. Treat cite-less output the same as an empty route.

Treating a route as a grant. A workflow ID means "this ticket belongs on this path," not "access is approved." Fulfillment systems must still evaluate policy, manager approval, and segregation-of-duties rules. Never map classifier output directly to role assignment APIs. If your pipeline cannot separate route from grant, fix the pipeline before deploying classification.

Invented confidence percentages. Some wrappers expose a "92% confident" score that implies mathematical certainty the model does not have. Operators chase thresholds ("auto-route above 80%") and bypass human review on numbers that are not comparable across requests or vendors. Use cite quality and catalog match as the review signal. If intent is unclear, the workflow field stays empty regardless of any numeric score your platform displays.

Watch for drift: new applications appear in chat before catalog updates, abbreviations change, or requesters copy boilerplate that mentions retired systems. Periodically sample routed tickets and compare cites to triager overrides. Patterns of override mean the catalog or training examples need refresh, not that you should auto-grant more aggressively.

Exceptions are normal. The classifier removes repetitive reading; humans keep judgment calls.

When a triager overrides the suggested workflow, capture the reason in a structured field. Those overrides become the best source of new training examples and catalog gaps. When a request is out of scope for any automated path, forward it to your existing expert queue with the original text and any partial cites attached, rather than forcing a low-fit workflow.

For tickets the classifier left blank, use a short decision tree: clarify with the requester, decompose multi-intent text, or escalate to IAM engineering when the ask does not map to any current template. Entitlement anomaly detection stays relevant after fulfillment, when you need to verify that what was granted matches what was requested.

Broader service desk automation can absorb adjacent work. Tier-1 autonomous resolution agent may handle password resets or client configuration while provisioning intent classification handles access routing; keep the boundaries explicit so a general resolver does not guess provisioning workflows.

Illustrative pass through one request. A contractor submits: "Need read-only access to the Finance reporting workspace in Microsoft 365 for audit support through March." The classifier returns workflow m365-finance-readonly-contractor with cite read-only access to the Finance reporting workspace in Microsoft 365 and leaves duration enforcement to the workflow's existing time-bound fields. A triager confirms the cite, confirms the end date is present in the ticket body, and starts the workflow. No entitlement is created until approval steps inside that workflow complete. If the same message omitted "Finance reporting workspace" and only said "need M365 access," the workflow ID would correctly stay empty until clarified.

Classification earns its place when triagers spend less time deciphering paragraphs and more time on the exceptions that actually require IAM judgment. Keep cites mandatory, grants downstream, and blanks honest.