Automation is the round where admin and developer interviews separate people who have built something from people who have only watched a demo. The panel asks how a catalog item turns into a request, which automation engine you chose and why, and what you checked when a flow stopped halfway. These 24 questions come from the RizeX Labs ServiceNow question bank and cover Flow Designer, the legacy Workflow editor, Service Catalog configuration, the request to RITM to SCTASK chain, and notifications and events.
Flow Designer questions
What is Flow Designer?
Flow Designer is the platform's automation builder. You define a trigger, then a sequence of actions and flow logic that runs when the trigger fires. It is built so an admin can automate a process without scripting every step, and it is the engine ServiceNow expects for new work.
Name four parts. The trigger, which is record based (created, updated, created or updated, deleted), scheduled, application based such as a Service Catalog item, or inbound email. The actions. The flow logic: If, Else, For Each, Wait For Condition, parallel branches. The data, passed between steps as data pills, action outputs and flow variables.
Each flow also has a Run As setting. System user runs with full access, User who initiates session runs with that person's roles and ACLs. Candidates forget this and then cannot explain why a flow that works for them fails for a normal user.
Difference between Workflow and Flow Designer?
| Point | Workflow editor | Flow Designer |
|---|---|---|
| Position today | Legacy, still runs, no new capability | Engine for all new build |
| Interface | Canvas of activities and transitions | Ordered trigger, actions and flow logic |
| Triggers | One table, started by a record or catalog item | Record, scheduled, application, inbound email |
| Reuse | Subworkflows | Subflows and actions with inputs and outputs |
| Scripting | Most non-trivial steps need script | Common operations need none |
| Integration | Custom REST or SOAP scripting | IntegrationHub spokes as ready actions |
| Debugging | Workflow context and log | Flow execution details, every input and output |
Workflow is still in production at most mature customers, because thousands of catalog items point at published workflows and nobody rewrites them without a reason. Flow Designer is for new requirements, anything needing a spoke, and automation not tied to one table.
What are actions?
An action is one reusable unit of work inside a flow. It takes inputs, performs steps, and returns outputs that later steps read. Base actions cover the everyday operations: Look Up Record, Look Up Records, Create Record, Update Record, Delete Record, Ask For Approval, Send Notification, Wait For Condition and Log.
You build your own in Action Designer when the same work repeats. An action that creates a fulfilment task with a fixed short description, assignment group and due date, exposed as three inputs, is a typical first custom action.
What are subflows?
A subflow is a reusable sequence of actions with its own inputs and outputs, called from a flow, from another subflow, or from script. An action is one operation; a subflow is a piece of process, such as a two level approval used by six different flows.
sn_fd.FlowAPI.getRunner()
.subflow('global.offboarding_checks')
.inBackground()
.withInputs({ user: current.getUniqueValue() })
.run();
Flow variables matter here. A subflow returns outputs, and the calling flow holds them in flow variables so a later branch can read a value produced eight steps earlier instead of repeating the lookup.
Can Flow Designer replace Business Rules?
Partly, and the honest answer scores better than yes or no.
A record triggered flow handles most of what an after or async business rule used to do: create tasks, send notifications, take approvals, call an integration. Business rules stay for what a flow cannot reach. Before insert and before update logic that sets or validates fields on the record being saved, because a record triggered flow runs after the record is written and asynchronously by default. Display rules that pass data to the client through g_scratchpad. Query rules that filter rows. Anything that aborts the transaction.
This is the point our trainers keep making: candidates know the syntax but not the execution. When it runs, where it runs and what data it can reach is what separates an answer that holds up from one that collapses on the follow-up.
Give any practical example of Workflow you have implemented?
Answer in four parts instead of drifting. Situation, approach, reason, result.
Situation. A laptop request item where procurement wanted manager approval before any cost was committed.
Approach. The process runs on the requested item. Ask For Approval to the requester's manager; on approved, a catalog task for the asset team and a second for desktop support to image and hand over; on rejected, the requested item closes incomplete.
Reason. Approval sits before task creation so no asset is reserved for an order that will be refused, and the tasks are separate because two groups own them.
Result. One request, one approval, two tasks, and a requested item that closes when both tasks are done.
Name the table behind each part, because the interviewer goes five levels deep on a project you claim: which table, what the requirement was, why this over the alternative, what your role was. Borrowed project stories disappear at the third question.
What the interviewer is actually checking
- Whether you can name more than the record trigger.
- Whether you know Flow Designer is for new build while Workflow is still live.
- Whether you use an action for one operation, a subflow for a process.
- Whether you can place the boundary between a flow and a before business rule.
- Whether your example survives questions about tables and decisions.
Service Catalog questions
What is Service Catalog?
Service Catalog is the front door where users order services and goods. It presents categories and items, collects details through variables, and starts the fulfilment process behind each item. Behind it sit sc_catalog, sc_category and sc_cat_item.
What is a Catalog Item?
A catalog item is one orderable thing: a laptop, a software licence, a new user account. The record holds the description and price, the variables that ask the user for details, and the process that runs on submission, which today is a flow and historically was a workflow.
What is an Order Guide?
An order guide bundles several catalog items into one ordering experience. The user answers common questions once, the guide decides which items apply, and the platform creates a single request holding several requested items. New hire onboarding is the standard example: one guide produces a laptop, a phone, an email account and a building pass. Two features are worth naming. Cascading variables copy an answer given in the guide into every included item, and the rule base decides which items are included, based on those answers.
Difference between catalog items and order guide?
| Point | Catalog item | Order guide |
|---|---|---|
| What it is | One orderable service | A container ordering several items at once |
| Table | sc_cat_item | sc_cat_item_guide |
| On submission | One request, one requested item | One request, several requested items |
| Variables | Belong to that item | Cascade into the included items |
| Item selection | Fixed | Rule base includes items by answer |
What is Variable Set?
A variable set is a reusable group of variables shared across catalog items. Define the employee details block once, attach it to twelve items, and one change updates all twelve. A single row set behaves like normal variables on the form. A multi row variable set collects repeating rows, for example five users to create in one request.
Types of catalog variables?
The expected list covers single line text, multi line text, numeric, select box, multiple choice, checkbox, yes or no, reference, list collector, lookup select box, date, date and time, duration, attachment, masked, URL, email and HTML, plus the layout types: label, container start, container split, container end and break. Choose reference over select box when the values already exist in a table.
What is Catalog Client Script?
A catalog client script runs in the browser on catalog variables, not on fields of a table form. It applies to one catalog item, to all catalog items or to a variable set, in the usual onLoad, onChange and onSubmit types, and it uses g_form against variable names. It works in the catalog view, in Service Portal and in record producers. Keep it light: it has no server data unless you fetch it with GlideAjax.
Difference between UI Policy and Catalog UI Policy?
A UI policy acts on fields of a table form such as incident. A catalog UI policy acts on variables of a catalog item, variable set or record producer.
The second difference is reach. A catalog UI policy has settings that control whether it also applies to the requested item form, the catalog task form and a record producer's target record, so the same behaviour carries into fulfilment. Both are preferred over client scripting for show, hide, mandatory and read only.
What is workflow in Service Catalog?
Every catalog item points at a process that runs on submission. In the older model that is a workflow attached to the item; in current builds it is a flow with a Service Catalog trigger. Either way it runs against the requested item, not the request, and it creates the approvals and catalog tasks and closes the requested item at the end.
Error handling belongs in this answer. If an action fails halfway, the requested item sits open with no task against it and the user chases the service desk. A flow handles this by wrapping the risky step, usually an integration call, so a failure follows a defined path: log it, set a state a human can see, notify the fulfilment group. Every run is recorded in flow execution details, where you read each action's inputs and outputs. When a panel asks why a requested item is stuck, going to that screen beats reciting what a flow is.
What the interviewer is actually checking
- Whether you can name the catalog tables without hesitating.
- Whether you can explain cascading variables and the rule base.
- Whether you reach for a catalog UI policy before a client script.
- Whether you know the process runs on the requested item, not the request.
- Whether you can say what you check when a request stalls.
Service request management questions
What is request management?
Request management handles everything a user asks for through the catalog, from submission to fulfilment. It gives each order an approval path, fulfilment tasks and a closure state. The chain has three levels:
- REQ on sc_request. The order, created at checkout, one per checkout.
- RITM on sc_req_item. One per item ordered, holding the variables and running the flow.
- SCTASK on sc_task. The fulfilment work created by that flow and assigned to a group.
Difference between request and incident?
A request is for something new or standard: access, hardware, software, a service. An incident is a break in service that has to be restored. If something that worked has stopped working, it is an incident. If nothing is broken and the user wants something provided, it is a request. Incident management is judged on response and resolution time, request management on delivery against the published fulfilment time.
What is RITM?
RITM is a requested item on sc_req_item, the working record of the catalog process. One line of the order, one RITM. It carries the variables the user filled in, it is the record the flow runs against, and it is the parent of the catalog tasks.
What is SCTASK?
SCTASK is a catalog task on sc_task, the unit of fulfilment work. The process on the RITM creates one task per piece of work, each with its own assignment group, and the RITM moves forward as tasks close. Tasks run in sequence, the second appearing only after the first closes, or in parallel where two teams work at once. Be ready to defend that choice.
What the interviewer is actually checking
- Whether you can walk REQ to RITM to SCTASK in order, with table names.
- Whether you classify request against incident correctly and say why it matters.
- Whether you know which record the automation runs on.
- Whether you can pick sequential or parallel tasks for a scenario.
Notifications and events questions
What is an Event?
An event is a signal that something happened, written to the event queue and processed later. Events are declared in the event registry so the platform knows the name and the table, and they are fired from server side script:
gs.eventQueue('incident.escalated', current, gs.getUserID(), current.assignment_group);
The two optional parameters carry values into whatever consumes the event. Firing an event that is not registered does nothing, which is the first thing to check when a notification does not arrive.
What is Event Queue?
The event queue is the sysevent table, where fired events wait to be processed. A scheduled job picks up events in the ready state, runs whatever subscribes to them, and marks them processed or error. Because this happens after the transaction, event work does not slow down the user's save.
The queue is also a diagnostic tool. Filter sysevent on your event name: if the event is not there, the problem is in your business rule; if it is there and processed but no email arrived, the problem is in the notification. Interviewers ask that debugging version more often than the definition.
How notifications are triggered?
A notification record on sysevent_email_action defines who receives it, what it says and when it goes. The When to send tab holds the trigger: either an insert or update matching a condition, or a named event. The platform then builds the message, applies the recipient list and writes it to the outbound email table for the send job.
Three settings decide whether anything reaches an inbox: the trigger condition, the recipient list, and the user's notification preferences. A correct notification still fails if the recipient switched it off or email sending is disabled on a sub production instance.
Difference between event-based and record-based notifications?
| Point | Record based | Event based |
|---|---|---|
| Trigger | Insert or update matching a condition | A named event in the queue |
| Logic sits in | The notification condition | The script that fires the event |
| Timing | With the record operation | Asynchronous, via the event job |
| Extra data | Only the record | Two parameters plus the record |
| Suits | Simple state changes | Scripted conditions, or several subscribers |
How many ways can we trigger notifications?
The common routes are an insert or update condition on the notification itself, a registered event fired with gs.eventQueue from a business rule, script include or scheduled job, a Notification activity in a workflow, and a Send Notification action in a flow. The last two name the notification record and send it at that point in the process, which is why a notification used by a flow does not always carry a condition of its own.
If the condition is a plain field change, keep it record based so the next admin can read it. If one signal must set off several outcomes, fire one event and let the notification and the script actions subscribe separately.
What the interviewer is actually checking
- Whether you know events are asynchronous and must be registered.
- Whether you can name sysevent and use it to debug a missing notification.
- Whether you choose record based or event based for a stated reason.
- Whether you know a flow and a workflow can both send a notification directly.
Taking this further
These answers are available in documentation. The interview is decided by the follow-up: which table, which trigger, what you checked when it failed. Build one catalog item end to end in a personal developer instance, put an order guide over it, run a flow that takes approval and creates two tasks, and add a notification driven by an event. Then break it and fix it, because that is the story you will tell in the room.
For that practice with a trainer's review, the ServiceNow training programme at RizeX Labs works through catalog, Flow Designer and request fulfilment on a live instance.