Request Management handles standard, expected asks from users: something new, access, information or a pre-approved service, such as a laptop, software, access to a shared folder or a password reset. Nothing is broken. The work is usually known in advance, ordered from the Service Catalog and often needs approval.

Incident Management handles unplanned interruptions: something that worked has stopped working or got worse, and the goal is to restore service as fast as possible.

In ServiceNow the difference shows in the records too: a request creates a Request (REQ) with Requested Items (RITM) and Catalog Tasks (SCTASK), driven by a fulfilment flow, while an incident is a single record worked by a support group with priority and SLAs.

Note: Routing requests through the catalog instead of incidents keeps incident numbers honest. Otherwise "I need a new mouse" ends up counted as an outage.

Opened by is the person who submitted the order. Requested for is the person who will receive the item or access. They are the same when you order for yourself, and different when a manager or assistant orders on someone's behalf, for example a laptop for a new joiner.

Why it matters:
- Approvals: manager approval should go to the manager of the Requested for user, not of the person who clicked Submit.
- Fulfilment: the laptop, account or access must be set up for the Requested for user, and their location or department often decides the fulfilment group.
- Notifications and portal views: both people usually need updates, and the requester should see the request under their requests on the portal.
- Security: catalog items can control who may order on behalf of others, so not everyone can request access for anyone.

Note: A common bug is a script or flow that uses the logged-in user (or Opened by) where it should use Requested for. Interviewers like candidates who spot this.

The three records each have their own state, and they roll up from the bottom:

Catalog Task (SCTASK): the actual work for a fulfilment group, with a normal task state (Open, Work in Progress, Closed Complete, Closed Incomplete, Closed Skipped).

Requested Item (RITM): one per item ordered. It has a state and a stage (for example Waiting for Approval, Fulfillment, Delivery, Completed). The fulfilment flow moves it on as its approvals and catalog tasks finish.

Request (REQ): the order as a whole. Its request_state moves from requested to in process, and the request closes once all of its requested items are closed.

So a request with a laptop and a monitor stays open until both items are delivered, even if one finished days earlier.

Note: Report and set SLAs on RITMs and tasks, where the work happens, not on the REQ.

Request-level approval applies to the whole order. Example: the requester's manager approves everything in the cart in one go, which is useful when the manager only cares about the total, not each item.

Item-level approval runs in the fulfilment flow of each Requested Item. Example: the software licence owner approves only the Visio request, and the security team approves only the admin access request.

In practice most implementations put approvals on the RITM, because different items need different approvers, and a rejection then only stops that item instead of the whole cart.

Note: Make approvers dynamic (the Requested for user's manager, the owner group of the software) instead of naming people, so approvals keep working when people move.

Stage describes where the item is in its fulfilment from the requester's point of view, for example Waiting for Approval, Fulfillment, Delivery and Completed. The fulfilment flow (or workflow) sets the stage as it moves through approvals and tasks.

On the Service Portal, the request page shows the stage as a progress tracker, which is what the requester sees. To make it useful:
- Use a few clear stages that mean something to the user, not internal team steps.
- Set the stage at the right points in the flow, for example Fulfillment when the task is created.
- Add customer-visible comments when something is waiting, so the requester knows why.

Note: State is for the process and reporting, Stage is for the requester. A good answer explains both.

Flow Designer is the recommended choice for new catalog items. Flows are easier to read and maintain, support reusable subflows and actions, have built-in catalog actions (such as getting catalog variables and creating catalog tasks) and show their execution details for troubleshooting.

Legacy Workflow still runs many existing items and is fine to maintain, but new items should not be built on it.

Execution Plans (delivery plans) are the oldest option: a fixed list of tasks with little logic. They are rarely used for new work.

A good design uses one flow for a family of similar items with conditions or a subflow for the differences, instead of copying a flow per item.

Note: When asked "how would you migrate", say: build new items on flows, and move existing workflows over when the item next needs a real change, rather than a big-bang rewrite.

SLAs for requests usually run on the Requested Item (the end-to-end promise to the user, for example a laptop delivered within 5 working days) and on Catalog Tasks (the internal targets for each fulfilment team, often set up as OLAs).

They rarely run on the Request itself, because a REQ can contain several unrelated items with different promises.

Good practice:
- Pause the SLA while the item is waiting for the requester or for approval, so teams aren't measured on time they can't control.
- Use schedules (business hours) and the right start condition, for example after approval.
- Measure: items delivered within target, average fulfilment time per item, time spent waiting for approval, and breaches per fulfilment group.

When an approval on a requested item is rejected, the fulfilment flow normally ends that item: the RITM is closed as incomplete or rejected, and no catalog tasks are created (any that were waiting are cancelled). If it was the only item, the Request closes too. A request-level rejection ends the whole order.

How to handle it well:
- Require the approver to give a reason, so the rejection comment explains why.
- Notify the Requested for user and the person who opened it, with the reason and what to do next (for example, order a different model).
- Make sure no task or SLA keeps running on the rejected item.

Note: Interviewers often follow up with "can the requester resubmit?". The usual answer is to order again with the changes, rather than reopening a rejected item.

1. Check the flow: open the RITM and look at its flow execution (Flow Designer) or workflow context. See which step it reached, whether it errored, or whether it is waiting on a condition that will never be true.

2. Check the data the flow needs: a missing assignment group, an empty variable used in a condition, an inactive user or group, or a lookup that returned nothing are common causes.

3. Check approvals: the approval may look approved on the form but still be pending for another approver or group in the flow.

4. Check for no flow at all: if the catalog item has no flow or workflow attached, nothing will ever create the task.

5. Recover the item: fix the root cause, then create the missing catalog task (or restart the flow where the platform allows it) so the requester doesn't have to order again. Tell the requester what happened.

6. Prevent it: handle errors in the flow, for example a fallback group when no assignment group is found, and report on RITMs that stay in the same stage too long.

Option 1: multi-row variable set (MRVS) and a flow. One catalog item with an MRVS where the manager adds one row per person. The flow loops over the rows and creates a separate Requested Item (or a catalog task) for each person, with its own approval. It is one form for the manager, and separate tracking per person.

Option 2: order guide. Good when the people need different items, but awkward for the same item 10 times.

Option 3: order the item 10 times (quantity or the cart). Simple, but quantity creates one RITM, and Requested for is the same for all, so it doesn't meet the requirement.

The MRVS design is usually the right answer: it keeps one Requested for per record, so approvals, access provisioning, SLAs and auditing are all per person.

Note: Mention limits: validate the rows (no duplicate users), cap the number of rows, and make sure each RITM's Requested for is set from its row.

Variables are available through current.variables on the RITM (and on catalog tasks for their item). Use getDisplayValue() for reference and choice variables when you need the label. A multi-row variable set returns its rows as JSON text, so parse it:

// Business Rule on sc_req_item, or a script step in the fulfilment flow
var laptopModel = current.variables.laptop_model.getDisplayValue();
var neededBy = current.variables.needed_by.toString();

// Multi-row variable set: one row per user
var rows = JSON.parse(current.variables.user_access_rows.toString() || '[]');
var lines = [];
for (var i = 0; i < rows.length; i++) {
    // row values are stored values (sys_ids for references)
    lines.push(rows[i].user + ' needs ' + rows[i].access_level);
}

// Copy the details into the catalog task created for this item
var taskGr = new GlideRecord('sc_task');
taskGr.addQuery('request_item', current.getUniqueValue());
taskGr.query();
while (taskGr.next()) {
    taskGr.setValue('description', 'Model: ' + laptopModel + '\nNeeded by: ' + neededBy + '\n' + lines.join('\n'));
    taskGr.update();
}

Note: Variable names are the variable's Name, not its question label. MRVS rows hold stored values, so reference columns contain sys_ids. Look them up once (for example, collect the sys_ids and query sys_user with IN) rather than querying inside the loop.

Use the CartJS API (sn_sc.CartJS). It orders the item the same way a user would: it creates the REQ and RITM, stores the variables and starts the item's flow and approvals.

var cart = new sn_sc.CartJS();
var request = {
    sysparm_id: '<sys_id of the "Standard Laptop" catalog item>',
    sysparm_quantity: '1',
    sysparm_requested_for: newJoinerSysId,
    variables: {
        laptop_model: 'standard_14',
        needed_by: '2026-11-03',
        delivery_location: officeSysId
    }
};
var result = cart.orderNow(request);
gs.info('Created ' + result.request_number + ' for the new joiner');

Why not insert sc_request and sc_req_item records directly? A plain insert doesn't store the variables properly, doesn't start the catalog item's flow or approvals, and can leave the REQ and RITM out of sync. Ordering through the catalog API keeps every request consistent with ones created on the portal.

Note: Look the catalog item up by name or a system property instead of hard-coding its sys_id in the script.

Use the Service Catalog REST API, which orders items exactly as the portal does:

POST https://<instance>.service-now.com/api/sn_sc/servicecatalog/items/<item_sys_id>/order_now
{
  "sysparm_quantity": "1",
  "sysparm_requested_for": "<user_sys_id>",
  "variables": {
    "software_name": "Adobe Acrobat",
    "business_justification": "Edit supplier contracts"
  }
}

The same API can also list catalogs and items, read an item's variables to build the form dynamically, and add items to a cart before submitting.

Why not insert into sc_req_item with the Table API? You get a bare RITM: no parent REQ (or a hand-made one), no variables stored the catalog way, no flow, no approvals and no catalog tasks. It looks like a request but nothing happens.

Note: Call the API as the end user, or pass Requested for, so approvals and user criteria apply to the right person.

Variable answers are stored in sc_item_option (one record per answer, pointing to the variable definition in item_option_new), linked to the RITM through sc_item_option_mtom. Query that link table once, filtering on the variable name and value, instead of loading every RITM and reading its variables in a loop:

var ritmIds = [];
var answerGr = new GlideRecord('sc_item_option_mtom');
answerGr.addQuery('sc_item_option.item_option_new.name', 'software_name');
answerGr.addQuery('sc_item_option.value', 'Adobe Acrobat');
answerGr.addQuery('request_item.active', true);
answerGr.query();
while (answerGr.next()) {
    ritmIds.push(answerGr.getValue('request_item'));
}

var ritmGr = new GlideRecord('sc_req_item');
ritmGr.addQuery('sys_id', 'IN', ritmIds.join(','));
ritmGr.orderBy('number');
ritmGr.query();
while (ritmGr.next()) {
    gs.info(ritmGr.getValue('number') + ' for ' + ritmGr.request.requested_for.getDisplayValue());
}

Note: For reference or choice variables, sc_item_option.value holds the stored value (a sys_id or choice value), not the label. Mention that this is also how you build reports on variable answers.