01 / JOB
A bounded job and named owner
Describe the operational job, success condition, exception and accountable team.
The useful question for an agentic workflow is not whether the agent can finish a task but at which point it must stop and wait. An agent that reads a record, drafts a reply, changes a field, closes a task and notifies a customer has crossed four different boundaries. Each carries a different consequence if the agent is wrong, and each needs its own permission setting. Treating the whole sequence as one permission is a common design error in this area. The table gives a practical way to decide the boundary for each kind of action. The ServiceNow solutions hub lists solution areas such as ITSM, ITOM and CSM that this boundary has to fit alongside.
| Action type | Typical boundary | What the reviewer needs to see |
|---|---|---|
| Reading records and context | Allowed within the sources named for the job | Which sources were read, and whether any were excluded |
| Recommending a classification or next step | Allowed, with no effect until a person or rule accepts it | The recommendation, its basis and a confidence signal |
| Preparing a draft or a change set | Allowed, staged for review | The proposed change shown against the current value |
| Changing a record the business owns | Only for an approved rule covering that exact change | The before and after values and the rule that permitted the change |
| Changing access, approvals or security settings | Not delegated to the agent | Nothing; this stays with a named person |
| Triggering a downstream system or outside message | Only after an approved integration contract and a failure route | The message content, the target and the reconciliation status |
Testing an agentic workflow only on the path it was designed for tells a team very little. A release review should exercise four paths, each with its own expectation. The normal path confirms that the job completes as described. The incomplete path tests what happens when a required field is empty or a linked record has been retired. The ambiguous path presents a request that fits two categories or two owners and checks that the agent asks rather than chooses. The failed path forces an integration error, a timeout or a rejected approval, and checks that the workflow leaves a visible state rather than a silent partial update.
The failed path is often the one skipped, and it is where much of the operational risk sits. A workflow that has changed a record in one system and failed to update a second system creates work nobody has been asked to do. The person who finds the gap may have no record of what the agent intended, which is why the intended change should be written down before it is applied.
Before release, the team should know how each agent action can be reversed and who has the authority to reverse it. Some actions have a clean reversal, such as restoring the previous value of a field from the record history. Others do not. A message that has already reached a customer cannot be unsent, and a status that has triggered a payment process in another system has to be unwound there. For the second group the answer is not a rollback but a correction route: who contacts the customer, who reverses the downstream effect and how the record shows that the correction took place.
Reconciliation links the two. A comparison, run per cycle or per batch, of what the agent intended against what actually changed gives the owner a short list to review. Without it, errors are found by the people they affect, which is the most expensive way to find them. Where the downstream change runs through an integration, the integrations and workflow orchestration page treats ownership, the failure route and the reconciliation path as part of defining the integration.
The first release is usually approved by a group that includes the workflow owner, the platform owner and whoever is accountable for each downstream system. The second and later releases are where agentic workflows tend to drift. A boundary gets widened to remove friction, a rule is added because a reviewer was busy, and the original reasoning is lost. A simple discipline prevents most of that. Any change to what the agent may read or act on goes through the same approval as the first release, and the change record names the earlier decision it modifies.
This page covers the design of the boundary, the test paths and the release controls. It does not choose which underlying model should power a workflow, and it does not treat a general AI policy as a substitute for the workflow’s own rules. A policy records what the organization intends. The workflow shows what the agent actually does, and only the second can be tested. The AI observability and human oversight page covers making an AI workflow understandable after it is used, including the context it received, what it produced and which tools it called. A team that wants to test a boundary before committing to it can start with a bounded AI workflow pilot.
Workflows where the owner is unclear, where a wrong action is hard to reverse or where the downstream system does not confirm receipt. A workflow with a clear owner, a reversible action and a visible confirmation is a much safer starting point.
Where possible, no. Staging the proposed change in a separate field or task keeps the reviewer’s view clean and makes it obvious which value came from the agent and which came from the people who owned the record.
There is no fixed number. The test set should cover each boundary the agent crosses and each failure route it can reach, and it should be reviewed whenever a boundary moves.
That can mean the proposals are good, or that reviewers have stopped checking. A sample of accepted proposals should be re-examined by someone who did not make the original decision before the workflow is widened.
Before any review, write down the ServiceNow workflow that is harder to run than it should be, the action an agent would be allowed to take and the person who would be affected by a wrong one. Those three items show whether the workflow is ready for an agent or whether its ownership and failure handling need fixing first. Start a conversation with them in hand.
Guides from the Oblytech ServiceNow library that explain the practice behind this page.