Automating Service Request Fulfillment

Every service request that sits in a queue waiting for a human to read it, classify it, route it, and manually execute a known fix is a small tax on productivity — and across a mid-size enterprise those small taxes add up to millions of dollars a year in lost engineer time and delayed employee outcomes. Agentic AI changes the economics of fulfillment by reading, reasoning, deciding, and acting inside the same workflow that used to require a person at every step, turning the service desk from a ticket-passing relay into a self-resolving control loop.

The service request problem: why fulfillment is still manual

Incident management gets the glamour in ITSM conversations, but service request fulfillment is where the volume actually lives. In most enterprises, requests — access provisioning, software installs, password resets, VM and storage allocation, onboarding and offboarding, VPN and MFA enrollment, printer and peripheral setup, distribution list changes — outnumber incidents by a factor of three to five. Despite that volume, request fulfillment has historically been the least automated part of the service management stack, because each request type requires its own combination of approval logic, entitlement checks, and downstream system calls.

The traditional fulfillment chain looks like this: an employee opens a portal or emails the help desk, a level-1 agent reads free text and guesses the correct catalog item, the item routes to a fulfillment group based on a static assignment rule, a human in that group manually executes runbook steps against Active Directory, a SaaS admin console, a cloud IAM policy, or a ticketing system, and finally someone closes the ticket and (rarely) confirms the employee is unblocked. Every one of those handoffs introduces latency, and every manual step introduces variance: the same request handled by two different technicians can take four minutes or forty, depending on experience, current queue depth, and whether the runbook documentation is current.

The result is a service desk that is perpetually behind, an employee population that routes around IT by asking colleagues or opening tickets under the wrong category to get faster attention, and a growing backlog of "quick" requests that never actually stay quick. Mean time to fulfill (MTTF) for access requests in unautomated environments commonly runs two to five business days; for anything requiring more than one system touch, it stretches further. Meanwhile the underlying task — add a user to a group, provision a mailbox, reset a password, expand a disk — is almost always deterministic, well-documented, and mechanically simple. The problem was never technical difficulty; it was the absence of a system that could reliably interpret intent, verify authorization, and execute the mechanical steps without a human being the connective tissue for every single instance.

Agentic automation closes that gap. Rather than a static workflow engine that only executes pre-mapped sequences, an agentic layer combines a reasoning model with tool access, memory of prior interactions, and guardrails, so it can interpret a request written in natural language, decide which catalog item and runbook applies, check policy and entitlement, and either execute directly or hand off cleanly to a human at exactly the point where judgment is genuinely required. This is the architectural shift covered in the rest of this article: how routing, auto-resolution, self-healing, and employee experience combine into a single deflection-and-resolution pipeline, and what it takes to build and govern one in production.

Anatomy of an agentic fulfillment pipeline

A production-grade agentic fulfillment system is not one model call bolted onto a ticketing tool. It is a layered pipeline with distinct responsibilities at each stage, because collapsing intent-understanding, policy-checking, and execution into a single opaque step is exactly how you end up with an agent that grants access it should not have, or resets the wrong account. The stages, in order, are: intake and normalization, classification and enrichment, entitlement and policy evaluation, routing and decisioning, execution (auto-resolution or self-healing action), verification, and closure with feedback capture.

Intake normalizes requests from every channel — a chat interface, email, a portal form, a Slack or Teams command, a voice transcript from an IVR, or a monitoring system opening a request on an employee's behalf — into a common structured representation before anything downstream touches it. Classification takes that normalized input and determines catalog item, urgency, affected service, and requester context (department, location, role, existing entitlements). Entitlement and policy evaluation is the layer that decides, independent of what the requester is asking for, whether they are allowed to have it, whether a second approver is legally or contractually required, and whether the target system's current state permits the change safely (change freeze windows, maintenance mode, capacity limits). Routing and decisioning is where the system chooses one of three paths: fully automated execution, execution with a human-in-the-loop approval gate, or full escalation to a specialist queue. Execution is where the actual work happens — API calls, script runs, orchestration playbooks. Verification closes the loop by confirming the target state actually changed (the account exists, the license is assigned, the disk is resized) rather than assuming success because an API returned 200. Closure captures outcome, updates the requester, and feeds the interaction back into the model's evaluation set so classification accuracy improves over time.

Each stage should be independently observable and independently testable. If classification silently degrades because a vendor changed a UI string the parser depended on, you want that failure visible at the classification stage — not discovered three stages later as a failed API call with an unhelpful error, or worse, not discovered at all because verification was skipped. This is the same discipline that mature platforms apply to AI-native operational stacks more broadly: reasoning, decisioning, and execution are separated so each can be governed, logged, and rolled back independently.

Intake, natural language understanding, and enrichment

The starting point for most requests is unstructured or semi-structured text: "I need access to the finance reporting share," "my laptop won't connect to the VPN after the update," "please add jane.jones@company.com to the marketing-analytics group like the rest of her team." A rules-based keyword matcher fails on this input constantly, because natural language is compositional and context-dependent — "add jane.jones to the marketing-analytics group" and "remove jane.jones from the marketing-analytics group" differ by one word that a keyword matcher weighted toward "marketing-analytics group" will happily treat as the same ticket type.

A large language model handling intake needs three things beyond raw text comprehension to be reliable in production: entity extraction grounded against a real directory of users, groups, and assets (not free-floating text spans); a controlled vocabulary of catalog items it is allowed to select from, rather than open-ended invention of new categories; and context injection from the CMDB and identity system before it commits to a classification. In practice this means the agent's first move on a new request is not to answer, but to query — look up the requester's actual department, manager, existing group memberships, device inventory, and location, and use that as grounding before deciding what "the finance reporting share" resolves to for this specific person. Ambiguity resolution matters more than raw accuracy on the happy path: a system that asks "do you mean the FY26 budget share or the AP reconciliation share?" when there are two candidates is more trustworthy than one that guesses silently and fulfills the wrong request with high confidence.

Enrichment also has to bring in signal the requester never typed. If someone requests VPN troubleshooting, the enrichment layer should pull recent authentication failures, current endpoint health posture, and whether there's an active regional outage affecting their office — because that context changes whether the correct action is "reset MFA token" or "no action needed, this is a known outage, notify and suppress duplicate tickets." This is where request fulfillment starts to overlap with monitoring and event correlation: the same enrichment pipeline that classifies a request should also be able to recognize that twelve similar requests in the last ten minutes are one underlying event, not twelve independent fulfillment cases.

A well-built intake layer typically achieves 85–92 percent classification accuracy against a catalog of a few hundred item types once it has a few months of labeled interaction history to draw on, with the remainder routed to a disambiguation prompt or a human triage queue rather than guessed. That confidence threshold — and where you set it — is one of the more consequential tuning decisions in the whole pipeline, discussed further in the routing section below.

Intelligent routing and triage

Routing in a legacy ITSM tool is a static lookup: category X always goes to queue Y. That model breaks down the moment volume, staffing, or specialization shifts, because the mapping has to be manually maintained and nobody updates it until the queue visibly backs up. Agentic routing replaces the static table with a decisioning step that considers request type, confidence of classification, current fulfillment-group capacity, requester risk profile, and policy constraints simultaneously, and it re-evaluates that decision on every request rather than relying on a rule written eighteen months ago.

The routing decision itself should collapse to one of three outcomes, and the discipline of forcing every request into exactly one of these three prevents the system from drifting into ad hoc partial automation that nobody can reason about later.

• Auto-resolve: classification confidence is high, the action is on an approved low-risk list, entitlement checks pass, and no policy flag (freeze window, elevated risk, prior fraud signal) is raised. The agent executes the runbook directly and verifies.
• Approve-then-execute: the action itself is auto-executable, but policy requires a named approver — a manager, a resource owner, or a security reviewer — before it runs. The agent pre-fills the approval context (who is asking, what they are asking for, why, what similar approvals looked like historically) so the approver's decision takes seconds, not minutes.
• Escalate to specialist: classification confidence is low, the request is genuinely novel, or it involves a system the agent has no execution rights against. The agent still adds full value here by pre-triaging: it attaches the enrichment data, a suggested resolution path, and relevant history so the human specialist starts from a filled-in ticket instead of a blank one.

Routing quality is measured less by how many requests get auto-resolved and more by how few get misrouted — a request auto-resolved incorrectly is far more expensive than one escalated unnecessarily, because the former produces a silent wrong outcome (wrong access granted, wrong system modified) while the latter merely costs a few extra minutes of human review. This asymmetry should directly shape confidence thresholds: err toward escalation for any action class where a false positive has security or compliance consequences (access grants, financial system changes, production infrastructure changes), and toward auto-resolution for action classes where a false positive is cheap to reverse (a password reset that turns out to be the wrong account is annoying but not dangerous, because the account owner will simply reset again).

Routing intelligence extends past the first assignment. If a request is escalated to a specialist queue and that specialist's resolution pattern is consistent and well-documented, the agent should be learning that pattern as a candidate for future auto-resolution — effectively promoting request types out of the human queue over time as confidence in the resolution pattern grows. This continuous promotion loop is what separates a system that plateaus at whatever automation coverage it launched with from one that keeps expanding deflection month over month.

Auto-resolution playbooks and self-healing runbooks

Auto-resolution is the mechanical heart of the system: a library of runbooks, each mapped to a catalog item or a class of request, that the agent can execute directly against target systems. The distinction worth being precise about is between auto-resolution (acting on an explicit employee request) and self-healing (acting on a detected condition before or without an explicit request being filed at all). Both share the same execution engine and the same guardrail model, but they differ in trigger: one is request-driven, the other is signal-driven.

A mature runbook library is organized by risk tier, not just by system or category, because risk tier is what determines whether a runbook is eligible for full automation, approval-gated automation, or human-only execution. Tier 1 runbooks are fully reversible, low blast radius, and well-understood: password resets, MFA re-enrollment, standard software installs from an approved catalog, mailbox size increases within policy limits, VPN profile reissuance, printer driver deployment. Tier 2 runbooks are reversible but carry moderate blast radius or touch sensitive systems: group membership changes affecting data access, VM resource scaling, temporary elevated access grants, guest account creation. Tier 3 runbooks are either hard to reverse or carry meaningful blast radius: production infrastructure changes, financial system entitlement, cross-tenant access, anything touching regulated data categories.

Each runbook should be written as a deterministic sequence of steps with explicit preconditions and postconditions, not as a loose prompt telling the model to "figure out how to do X." The agent's judgment is applied at the decision layer — which runbook applies, whether preconditions are met, whether to proceed — while the runbook execution itself is deterministic and auditable, essentially a codified script that the agent invokes as a tool rather than free-form action it improvises token by token. This distinction is the difference between an agent you can certify for a SOC 2 or ISO 27001 audit and one you cannot: auditors need to see that the same input produces the same execution path every time, with model reasoning constrained to selection and validation rather than open-ended system manipulation.

Worked example: onboarding a new hire

Consider a new-hire onboarding request, historically one of the highest-touch fulfillment workflows because it spans identity, email, endpoint provisioning, application access, and physical access in a single case. An agentic pipeline handles this as a single logical request that fans out into a coordinated sequence: create the AD/Entra ID account from the HR system record, provision the mailbox with the correct retention policy, assign the license bundle matching the employee's role template, add the employee to role-based security groups (derived from a matrix, not from guesswork), trigger MDM enrollment for a pre-staged device, request badge access from facilities with the correct building and floor scoped to their office assignment, and schedule a day-one welcome message with credentials delivered through a secure, time-limited channel rather than plaintext email.

Every one of those seven sub-actions has its own precondition (does the role template exist, is the device already staged, is the badge system online) and its own verification (does the mailbox actually exist and accept mail, does the device show as enrolled in MDM, does the badge system confirm the access profile is active). If any sub-action fails, the orchestrator should not silently mark the overall case complete — it should hold the case in a partially-fulfilled state, notify the fulfillment team of exactly which sub-action failed and why, and retry with backoff for transient failures (an identity provider API timeout) while escalating immediately for structural failures (the role template doesn't exist because HR entered a title that doesn't map to anything).

Worked example: self-healing disk capacity

Self-healing looks different because there is no employee request to classify — the trigger is a monitoring signal. A disk utilization alert crosses 85 percent on a file server. Instead of opening an incident for a human to investigate, the self-healing pipeline checks whether this volume is on an approved auto-expand policy, checks current growth rate against historical baseline to rule out a runaway process rather than organic growth, checks whether expansion capacity exists on the underlying storage pool, and if all conditions are met, executes the expansion, verifies the new capacity is visible to the OS, and only then closes the loop with a low-priority notification rather than a page. If growth rate is anomalous (10x baseline in the last hour, suggesting a log file spiraling or a runaway process rather than natural growth), the system should refuse to auto-expand and instead escalate with the anomaly flagged, because blindly expanding storage in front of a leak just delays the real problem and burns capacity.

This same self-healing pattern extends to certificate renewal before expiry, service restarts on detected crash-loop patterns within defined retry limits, cache clearing on detected memory pressure, stale session cleanup, and license reclamation from inactive accounts. The throughline across all of these is that the system is closing a loop that a human would otherwise have to notice, triage, and act on manually — and doing it before the condition becomes visible to the employee as an outage or slowdown at all, which is the deepest form of deflection because no ticket is ever filed.

Approval orchestration and policy guardrails

Not every request should be fully autonomous, and pretending otherwise is how automation programs lose trust after one bad incident. The approval layer's job is to make human sign-off fast and well-informed for the subset of requests that genuinely need it, rather than eliminating human judgment or, at the other extreme, routing everything through a rubber-stamp approval that adds latency without adding real oversight.

Policy-as-code is the mechanism that makes this maintainable at scale. Rather than embedding approval logic in prompts or scattering it across workflow tool configurations, approval rules should live in a structured, versioned policy store that both the agent and human auditors can read: which request types require an approver, who that approver is (a static role, the requester's manager, a resource owner, a security team), what conditions escalate an otherwise-single-approver request to require a second signature (dollar thresholds, access to regulated data, requests originating from a device with failed compliance posture), and what the default action is if an approver does not respond within an SLA window (auto-escalate, auto-deny, or auto-approve after a defined delay for genuinely low-risk items).

The agent's contribution to approval quality is contextual pre-briefing. A manager asked to approve "add jane.jones to marketing-analytics" with zero context takes longer to decide and is more likely to rubber-stamp without real scrutiny than a manager shown: "Jane Jones (Marketing, hired 14 months ago) is requesting access matching 4 of 5 peers on her team; the fifth peer's access was removed 3 months ago during a role change. No policy conflicts. Estimated risk: low." That second version is a decision an approver can make confidently in ten seconds, and it is also a decision that holds up under audit scrutiny because the reasoning is documented at the time of approval, not reconstructed after the fact.

Guardrails need to operate at multiple levels simultaneously: identity-level (does the requester have authority to ask for this on behalf of themselves or someone else), resource-level (is the target system in a state where this change is safe — not mid-maintenance, not at capacity, not already subject to a conflicting pending change), and temporal (change freeze calendars, business-hours-only execution windows for higher-risk actions, blackout periods around financial close or major releases). A well-governed platform treats these guardrails as first-class, independently testable policies rather than scattered if-statements, which is the same governance posture that identity and privileged access management programs apply to human access — agentic execution accounts deserve the same least-privilege discipline as any other identity, arguably more, since they act at machine speed and volume.

Integration architecture: CMDB, ITSM, identity, and endpoints

None of the reasoning described above is worth anything without reliable, low-latency access to the systems of record that ground it. The integration layer is frequently underestimated in build-versus-buy conversations because it looks like plumbing, but it is where most production incidents in agentic fulfillment programs actually originate — not from the model reasoning poorly, but from the model reasoning correctly against stale or incomplete data.

A functioning integration architecture needs, at minimum: a CMDB or asset inventory that is genuinely current (not a nightly batch sync that is eighteen hours stale by the time a request is evaluated against it), a directory service (Active Directory, Entra ID, Okta, or equivalent) queried in real time for group membership and entitlement state, the ITSM platform itself as the system of record for the ticket lifecycle, an orchestration layer (RPA-style connectors, API gateways, or a workflow engine) that actually executes runbook steps against target systems, and an event bus or monitoring integration that feeds self-healing triggers. The agent sits above these systems as a reasoning and decisioning layer, calling into each through a well-defined tool interface rather than embedding direct database or API credentials in the model's own context.

This layering matters for a concrete operational reason: when something goes wrong, you need to know immediately whether the failure is a reasoning failure (the agent picked the wrong runbook) or an integration failure (the right runbook was picked but the target API rejected the call, or returned stale data). Collapsing these layers into a single monolithic "AI does everything" black box makes that diagnosis nearly impossible, which is precisely why platforms built for production ITSM automation, including the approach behind ITMox, keep model-driven decisioning and deterministic execution as separate, independently observable stages connected through typed tool interfaces rather than free-form prompting all the way down to the API call.

Latency budgets matter more than they get credit for in architecture discussions. An employee who asks a conversational assistant for VPN help and waits eleven seconds for a directory lookup before getting a response has already formed an opinion about whether this is faster than emailing the help desk. Real-time or near-real-time reads against identity and CMDB systems, with aggressive caching for data that changes slowly (org hierarchy, device inventory) and no caching at all for data that changes fast (current entitlement state, open change windows), is a design requirement, not an optimization to defer.

Employee experience: conversational fulfillment and the disappearing help desk

The measure of success for a fulfillment automation program is not internal automation percentage — it is whether an employee's experience of getting unblocked actually got faster and less frustrating. A system that hits 70 percent auto-resolution on the back end but still forces employees through a twelve-field portal form to file the request in the first place has only solved half the problem, because the friction employees actually feel is often at intake, not at fulfillment.

Conversational intake through chat (Slack, Teams, a dedicated app) or voice removes the largest source of friction: instead of navigating a service catalog tree to find the right form, an employee describes what they need in their own words and the agent handles classification. This only works if the conversational layer is willing to ask clarifying questions rather than guessing, and if it gives the employee visibility into what is happening — "I've verified you have the same role as your team and I'm provisioning access now, this should be ready in under two minutes" is a fundamentally different experience from a ticket number and silence for three days.

Proactive status updates matter as much as initial responsiveness. Employees tolerate a request taking longer than expected far better than they tolerate not knowing whether anything is happening at all. An agentic system that pushes a status update the moment an approval is pending ("waiting on your manager's approval, sent 3 minutes ago"), the moment execution starts, and the moment it verifies completion closes the anxiety gap that drives duplicate ticket filing and escalation-via-annoyance, both of which inflate apparent ticket volume without reflecting real additional work.

This is also where an agentic workforce layer like Norra becomes relevant beyond IT specifically: the same pattern of an AI agent handling intake, verifying context, and executing or routing appropriately generalizes to HR requests, facilities requests, and finance approvals, and organizations that build this capability once for IT service requests typically find the underlying agent framework — conversational intake, policy-grounded decisioning, deterministic execution, verification — reusable across every internal service function rather than IT-specific.

Employee trust in the system compounds or erodes based on visible failure handling, not just success rate. When the agent gets something wrong — provisions the wrong access level, misunderstands the request — the recovery experience (a fast correction path, an easy way to flag "this isn't what I asked for" that routes immediately to a human, not another round of the same automated loop) determines whether employees keep trusting the conversational channel or quietly revert to emailing a known human they trust. Programs that skip investment in graceful failure recovery see adoption plateau regardless of how good the happy-path automation is.

Metrics: what to measure and how to prove the value

Deflection percentage is the headline metric everyone reaches for, but used alone it is a dangerous metric because it rewards aggressive auto-resolution regardless of accuracy. A program that "deflects" 80 percent of requests by auto-approving everything without real policy checks will show a great top-line number and a terrible audit finding six months later. Deflection has to be reported alongside accuracy and reversal metrics for it to mean anything.

Cost modeling for these programs should account for fully-loaded technician time saved, not just ticket count reduced, because a ticket that used to take a level-2 technician forty minutes to research and execute is worth far more to eliminate than one that took ninety seconds. Weighting deflection by historical resolution time per request type, rather than treating every deflected ticket as equal, produces a much more honest ROI figure and correctly prioritizes automation investment toward the request types that were actually expensive, not just the ones that were numerous.

Leading indicators worth tracking alongside the lagging metrics above include model confidence distribution drift (are confidence scores creeping down over time, suggesting the underlying systems or request patterns are changing faster than the model is being retrained), approval rubber-stamp rate (approvers clicking approve in under five seconds on high-risk categories is a governance red flag, not a speed win), and duplicate ticket rate (a proxy for employees not trusting that their first request is being handled).

Governance, security, and the audit trail

Every auto-resolved or self-healed action is, from a security and compliance standpoint, a privileged action taken by a machine identity, and it needs to be treated with the same rigor as any privileged human action: full audit logging of what was requested, what data grounded the decision, what policy check was applied, what was executed, and what the verified outcome was. This audit record needs to be immutable and queryable, not just log lines scattered across the orchestration tooling, because the question an auditor or incident responder asks six months later is rarely "did this work" — it is "why did the system decide this was authorized," and that answer needs to be reconstructable from the record, not from institutional memory.

The execution identity the agent uses matters as much as the reasoning that drives it. Agent execution accounts should follow least-privilege scoping specific to each runbook tier — a Tier 1 password-reset runbook's service account should not hold the same broad directory-write permissions as a Tier 2 group-membership runbook, and neither should share credentials with the reasoning layer itself. Credential and secret handling for these execution paths should route through the same vaulting and rotation discipline applied to any other automation identity, and access to modify runbook definitions or policy rules should itself require change control — the runbook library is effectively a codebase and deserves the same review rigor as production code, including version control, peer review before merging a new or modified runbook, and staged rollout (shadow mode, then approval-gated, then fully autonomous) for any new automation.

Shadow mode deserves specific mention as a rollout discipline: before any new runbook or request category goes fully autonomous, run it in observation mode where the agent produces its decision and proposed action but a human reviews and executes manually, comparing the agent's proposed action against what the human actually did. This surfaces edge cases and policy gaps before they become production incidents, and it produces the evidence base needed to justify promoting a request type from human-only to approval-gated to fully autonomous with actual data rather than a leadership mandate to "automate more."

Regulatory and sovereignty considerations shape architecture choices directly in regulated industries and government contexts. Air-gapped and sovereign deployments — a real requirement for defense, critical infrastructure, and public sector environments — need the entire reasoning and execution pipeline to run without external API dependency, which is a materially different engineering problem than a SaaS chatbot calling a hosted model API, and it is why platforms serving these environments architect for on-prem and air-gapped model hosting from the outset rather than retrofitting it. Data residency requirements similarly determine where enrichment data (which often includes PII from HR and identity systems) can be processed and cached, and this has to be a first-class architecture decision, not an afterthought bolted on after a pilot succeeds in a cloud sandbox.

Implementation roadmap and maturity model

Organizations that succeed with agentic fulfillment do not start by trying to automate everything; they start with a narrow, high-volume, low-risk request category, prove accuracy and reversal metrics are genuinely healthy, and expand deliberately. A practical four-phase roadmap looks like this.

1. Phase 1 — Foundation and shadow mode (months 1–3): Instrument the top 15–20 request types by volume, build the integration fabric to CMDB, identity, and ITSM, run classification in shadow mode against real traffic with human fulfillment continuing as normal, and measure classification accuracy against actual outcomes before any automation goes live.
2. Phase 2 — Tier 1 auto-resolution (months 3–6): Turn on full automation for the handful of Tier 1, reversible, high-confidence request types — password resets, standard software provisioning, basic access requests matching an existing peer template — with verification and rollback built in from day one, not added later.
3. Phase 3 — Approval-gated expansion (months 6–12): Extend into Tier 2 categories with approval orchestration, focusing engineering effort on making the approval experience fast and well-contextualized rather than just wiring up more request types, and begin the self-healing program on well-understood infrastructure signals (disk capacity, certificate expiry, service restarts).
4. Phase 4 — Continuous promotion (ongoing): Establish the feedback loop that promotes request types from human-only to auto-resolved based on accumulated accuracy evidence, and extend the same agent framework to adjacent domains (HR service requests, facilities, finance approvals) rather than treating IT automation as a one-off project.

A common failure pattern worth naming explicitly: organizations that try to automate their highest-volume request type first because the ROI math looks best, without checking whether that category is actually low-risk and well-understood. High volume and low risk are not the same axis, and optimizing for volume alone before risk is validated is how automation programs produce their first serious incident in month two rather than month twelve, souring leadership on the entire initiative long before it had a chance to mature.

Figure 3 — The four pillars of an agentic fulfillment program working in concert.

Programs also benefit from treating this as connected to broader operational resilience rather than an isolated ITSM project. The same agent reasoning and integration fabric that resolves a service request also has visibility into related operational and security signals, and organizations running integrated NOC/SOC operations increasingly find that request fulfillment, incident response, and security triage share more infrastructure than their org chart suggests — a disk-capacity self-heal and a security-relevant configuration drift detection are architecturally the same pattern of signal-in, policy-check, remediate, verify, even though one lives in ITSM and the other might live closer to alert triage workflows.

Frequently asked questions