ServiceNow workflow data and context design that supports decisions

Test whether the next owner could act without asking

A simple test shows whether a workflow’s data is doing its job. Take a handoff from last month and show the record to the person who received it, with nothing else. Could they say what is being asked of them, what has already been decided, and what would count as finished? If they had to telephone the previous owner, open three other systems or read a thread of comments to answer, the context did not travel. The test costs little and reveals the gaps that matter, because it runs on real records rather than on a specification. Repeat it for each handoff type, and keep the records where the answers failed, since those are the design defects to fix.

Build the field inventory around decisions, not screens

Teams that design workflow data often begin with the form and add every field a user might want. A better starting point is the decision. For each decision in the workflow, list the facts needed to make it and mark each one as required, helpful or irrelevant. A required fact that is missing should block the step or route it to an exception. A helpful fact can be shown but must not gate the step. Irrelevant fields are the usual source of noise, and removing them from the handoff is often the largest single improvement.

Use reason codes a second person can read

Free text is useful to the person who wrote it and poor for the person who receives the work. A reason code, chosen from a short list that each team has agreed, lets a receiving team sort, report and automate on the situation. The codes should describe the situation rather than the action, so that waiting for customer detail is clearer than follow up. Keep a free-text note alongside the code for detail, but do not let the note become the only record of why a decision changed. Review the list each quarter, removing codes nobody uses and merging codes that people choose interchangeably. The display value that a reader sees on a form is a further place where a code can read differently from the stored value, and the list should be checked against it.

Separate a recorded fact from a judgment made about it

When a workflow marks a request as overdue, two things are true at once: a date has passed, and someone has judged the work late against an agreed target. Mixing the two creates disputes, because one team may argue the date was not late for its part of the process. Store the underlying date as a fact, and show any judgment as derived from it, with the rule that produced it. The same applies to a status such as on hold. The record should say which party placed the hold and which condition releases it, so the next owner does not inherit a status with no explanation. Reports built on these statuses should use the same rule, so that a figure in one report cannot disagree with a figure in another.

Give automated steps a stop path that explains itself

An automated step should explain itself when it stops, not only when it succeeds. A stop path needs three things: the condition that caused the stop, the record and its current state, and a named person or group who decides the next action. Place that explanation where the person will see it, usually on the record or in the task assigned to them, rather than in a log that only administrators read. The context a person needs to take over should be the same context the automation writes when it halts. The business rule or flow that stops should write its reason as a field, not only as a message, so that the stop can be filtered and counted. Designing both together means the automation does not remove information that a human would otherwise have had.

Decide what travels and what stays on the source record

Passing the whole record to every downstream step creates a second copy that goes out of date. A better pattern passes a reference to the source record, the minimum facts needed for the next decision, and the question the receiving team must answer. The source record remains the place where full history is kept. If a receiving team needs more, it follows the reference rather than relying on a snapshot. That keeps handoffs short and stops the receiving system from becoming an unofficial store for data it does not own. Queries that select records for the receiving team can be defined with an encoded query, so the selection rule is explicit and reviewable.

Questions about designing workflow context

How many fields should a handoff carry?

As few as the next decision needs, plus the reference that lets the receiving team find the rest. A handoff carrying dozens of fields often includes many that nobody reads. Use the field inventory to decide, and review it whenever the decision changes.

Should different teams use the same status names?

Only where the names mean the same thing. A status called in progress may mean assigned in one team and actively worked in another. Either rename the statuses so each is distinct, or record the meaning in the status definition so every report that uses it reads the same way.

Who maintains the context design after go-live?

The process owner, with the platform team making changes through the normal release route. Context needs change when a team takes on a new decision, and that is usually when handoffs begin to fail.

Measuring whether context is improving

Track the handoffs that are sent back, the questions that arrive through a handoff channel after the record has been passed, and the number of times a person reopens a source record to find a missing fact. These measures are imperfect, but they show the direction of change. Review them with the process owner at a fixed point, and run the next-owner test on a sample of records to confirm what the measures suggest. Where the workflow depends on connected systems, the data governance and source authority route covers which source is authoritative for a field, who owns its meaning and what happens when sources disagree.