ServiceNow Flow Designer Requirements Workshop Questions

This page lists the questions to put to a group before a Flow Designer flow is built, and the answers that change the build. It covers the trigger, the data, the integrations, the exceptions, the notifications and the performance targets, and it flags the answers that signal an unready process.

Process Understanding Questions

Start by understanding what process will be automated. Ask: what is the trigger for this flow? What are the main steps? In what order do they occur? Are there decision points or branches? What information must flow from step to step?

Question: “What happens today without automation?” Answer shapes entire flow structure. If process is manual today, flow must replace manual steps. Answer tells you how many decisions and approvals the flow must handle. A process with 10 manual steps needs a flow with 10 automated steps.

Question: “Are there timing requirements? Must something happen immediately, or is timing flexible?” Answer affects flow design. If action must be immediate, flow must be synchronous. If timing is flexible, flow can be asynchronous and handle higher volume. Synchronous flows are simpler; asynchronous require queuing and monitoring.

Question: “Who participates in this process today?” Answer identifies who will receive flow notifications or actions. If only one person does the work, flow goes one direction. If multiple people are involved, flow must handle parallel paths and coordination.

Data and Integration Questions

Question: “What data drives this process? What information do people use to make decisions?” Answer shapes what data the flow must collect or look up. If process uses customer name to route work, flow must capture or look up customer. If decisions depend on account balance, flow must fetch account data.

Question: “Does this process need to integrate with other systems?” Answer determines complexity and risk. Flows with no integrations are simple. Flows that integrate with 3 external systems are complex. Each integration is a potential failure point.

Question: “What information must flow to other systems? How is it formatted?” Answer shapes data transformation. If another system expects data in specific format, flow must transform. If systems expect different data structures, flow must map carefully.

Question: “What happens if an integration fails? Should flow retry, notify someone, or proceed despite the failure?” Answer shapes error handling. Different processes tolerate failures differently. A payment processing flow cannot tolerate failure. An informational notification can retry or fail gracefully.

Business Logic Questions

Question: “What decides if an approval is needed?” Answer shapes flow branches. If all requests need approval, flow has one path. If some requests bypass approval based on criteria, flow has conditions. For example, requests under a spending limit may auto-approve.

Question: “What should happen if something goes wrong? Is there a rollback process?” Answer shapes error handling. Can a flow be undone if step 5 fails? Must flow pause and notify someone? Must flow rollback steps 1-4? Rollback is complex; most flows pause and notify instead.

Question: “Are there audit or compliance requirements? What must be recorded?” Answer shapes logging and tracking. If flow must prove who did what and when, flow must capture audit trail. If process is audited, flow must create records that satisfy auditors.

Exception and Edge Case Questions

Question: “What if required data is missing? Do you have default values, or does flow pause?” Answer shapes how flow handles exceptions. If data is missing but flow has default, flow can proceed. If data is critical and missing, flow must pause and notify. Missing data handling prevents silent failures.

Question: “What happens with duplicate requests? Can the same request be submitted twice?” Answer shapes idempotency. If duplicates are possible, flow must detect and handle. If flow runs twice with same data, does it process twice or recognize as duplicate? Preventing duplicate processing is important.

Question: “Are there volume or scale concerns? How many times per day will this flow run?” Answer affects architecture. A flow running 10 times a day is simple. A flow running 10,000 times a day needs optimization, caching, and parallel processing. Scale concerns change design.

User Notification Questions

Question: “Who needs to know when this flow runs? What information do they need?” Answer shapes notifications. If an approver must act, they need full request details. If someone is being notified for information only, they need summary. Information needs shape notification content.

Question: “When should notifications be sent? Immediately, or at a scheduled time?” Answer shapes notification strategy. Real-time notifications are urgent—approval requests. Scheduled notifications are routine—daily summary. Response time expectations differ.

Question: “What should happen if notification is not delivered? Should flow retry, use alternate notification method, or escalate?” Answer shapes notification reliability. Critical approvals may escalate if not opened. Informational notifications may just retry once.

Performance and Monitoring Questions

Question: “How long should this flow take to complete? What is acceptable?” Answer sets performance targets. If flow completes in 5 seconds but your expectation is 1 second, flow needs optimization. Acceptable performance varies by process.

Question: “How will you know if the flow is working correctly? What metrics matter?” Answer shapes monitoring. Track flow completion count, success rate, average duration. If success rate drops, something is wrong. Metrics guide investigation.

Question: “How frequently should this flow be reviewed or updated?” Answer shapes maintenance. Some flows change rarely; review annually. Others change frequently due to business changes; review monthly. Update frequency affects review schedule.

Warning Signs in Answers

If stakeholders are vague about process, that is a warning sign. “It varies” or “people do it differently” means process is not standardized. Before automating with flow, standardize the process. Flows automate standard processes, not ad hoc approaches.

If stakeholders cannot describe decision criteria, that is a warning. “We just know” suggests human judgment that is hard to automate. Flows handle rules-based decisions. Complex judgment may be better left manual or handled by AI, not Flow Designer.

If stakeholders mention “it has never failed” but also “we have workarounds”, that is a warning. The process probably has hidden failures that workarounds mask. Automated flow will expose these issues. Plan for this reality.

Documentation and Follow-Up

Document requirements thoroughly. Decisions made in workshops should be captured before memory fades. Use decision matrix: for each requirement, note business owner, approval, and date. This creates a trail you can refer to later.

Share documented requirements with stakeholders for confirmation. “This is what we understood” gives stakeholders chance to correct misunderstandings before development starts. Misunderstandings found in requirements phase are cheap to fix. Misunderstandings found in production are expensive.

Run the workshop around the answers that would change the build

A requirements workshop for a flow can easily run long and still leave the analyst unable to draw the flow. The reason is often that the questions were broad and the answers were polite. The questions below are chosen for the answers that change what gets built: the trigger, the branch points, the records touched, the failure route and the people who must act. For each question the table shows what a usable answer sounds like and what a warning answer sounds like, so the facilitator can tell when to press for detail rather than move on.

Ask about the people, not only the process

Flows change the work of the people around them, and a requirement that ignores those people often returns as a complaint in the first weeks. Ask who receives a notification, who must act on it, and what they do if they are away. Ask whether the people involved already have access to the records the flow will update, and whether any of them currently works around a control that the flow would enforce. Those answers shape notification design and access, and they surface resistance early enough to plan for it.

1. Open with the purpose of the process and the outcome the business wants, in one sentence agreed by the sponsor.
2. Walk through one typical case from start to end, asking the process owner to narrate it rather than list it.
3. Ask the question about exceptions next, while the typical case is still on the screen, and record each exception type.
4. Cover the failure route: what happens when a call fails, a record is missing or an approver does not respond.
5. Ask about records, fields and integrations, confirming which systems are the source and which are the target.
6. Close by reading back the trigger, the branches and the outcomes, and asking the group to correct any one of them.

Capture the decisions, not the discussion

A useful output of a workshop is a short list of decisions, each with the person who made it and the date. Discussion notes age quickly and are often not reread. For each decision, record what was decided, what was rejected and why, and what would cause the decision to be reopened. An open question should have an owner and a date by which it must close. A requirement that the group could not settle is a risk, and it belongs on the risk list rather than being written as if it were agreed.

Notice when a workshop is not ready to produce a flow

Some workshops should end without a flow requirement, and saying so is a good outcome. If the process differs between teams and nobody will agree a single version, the flow would automate a disagreement. If the decision criteria are held only by one experienced person who is unavailable to the build, the automation will be guesswork. If the group keeps describing the process as it should be rather than as it is, a shadow process can appear the moment the flow goes live. In those cases, the next step is standardization work, not a build.

How many people should attend?

Enough to cover the decisions, and no more. One process owner, one person who does the work, one technical lead and one person who will support the flow after go-live is a workable core. Larger groups tend to produce agreement on what is uncontroversial and defer the hard decisions.

Should we send the questions in advance?

Send the first two or three, so people can bring real examples. Sending the full list can make the session feel like an exam and encourages prepared answers rather than honest ones.

What if a stakeholder keeps proposing new features?

Record each one as a candidate for a later release, with the reason it was raised, and ask the group to confirm what the first release must do without it. That keeps the scope honest without dismissing the idea.

How soon should the requirement be confirmed in writing?

Soon, while the reasoning is fresh. Share the written version with the attendees for correction before any build estimate is made, because misunderstandings found at that stage are the cheapest to fix.

Once a requirement is settled, the testing and acceptance checklist shows how it will be proven, and the requirements workshop decisions article covers recording outcomes.