ServiceNow actions

Who this is for: people and AI assistants who write workflow steps that open or follow up ServiceNow incidents and requests, for example to raise an incident from a monitoring alert or to order a laptop for a new starter.

Before you start: you need a ServiceNow connection. See Connect ServiceNow.

These actions are part of our curated platform library. Use them in any workflow as uses: library/servicenow.<name>@v1. Each action uses one connection slot, servicenow, which takes a connection made from the ServiceNow template. You find the same actions in the app under Library, and your AI assistant reads their full contracts with the MCP tool get_action.

Action	What it does	ServiceNow role it needs
`library/servicenow.get-incident@v1`	Reads one incident (only reads)	a role that reads incidents, such as `itil`
`library/servicenow.find-incidents@v1`	Lists incidents that match your conditions (only reads)	a role that reads incidents, such as `itil`
`library/servicenow.create-incident@v1`	Creates one incident	`itil` or `sn_incident_write`
`library/servicenow.update-incident@v1`	Changes fields of one incident	`itil` or `sn_incident_write`
`library/servicenow.add-note@v1`	Adds a work note or a comment to an incident or a request	a role that updates the record, such as `itil`
`library/servicenow.create-request@v1`	Orders one catalog item, which creates a request	a role that may order the item
`library/servicenow.get-request@v1`	Reads one request or requested item (only reads)	a role that reads requests, such as `itil`
`library/servicenow.update-request@v1`	Changes fields of one request or requested item	a role that updates requests, such as `itil`
`library/servicenow.find-user-by-email@v1`	Finds users by email address (only reads)	a role that reads users, such as `itil`

Give the integration user only the roles for the actions you use. See Connect ServiceNow.

What every action does the same way

Field names, not labels. Fields are named by their system name, such as short_description or assignment_group, not by the label you see in ServiceNow. To find one, open a form in ServiceNow, right-click a field label and look at the name it shows, or ask your ServiceNow admin.
Database values. Values go in and come out as database values, not as the text you see on a form. A reference, such as the caller, is the sys_id of the record it points to. A choice, such as the state, is its stored value, like 2. Those values can differ between instances, so check them in yours.
Only the data you ask for. Each reading action asks ServiceNow for a short list of fields by default. Use fields to choose others. Ask only for what the workflow needs: it keeps personal data out of your runs and makes requests faster.
Pages, with a limit. servicenow.find-incidents reads long lists a page at a time, up to max_pages pages and max_items incidents. ServiceNow leaves out records the integration user may not read only after it has cut a page, so a page can be short or even empty while more follow. The action keeps reading while ServiceNow says more follow, and when more was left, the output says truncated: true.
Conditions stay conditions. ServiceNow joins conditions with ^, and its documentation doesn’t say how to put a ^ inside a value. So a value with ^ is refused, and so is one that starts with javascript:, before anything is sent. No value can add a condition or widen a search.
A misspelt field never returns other records. ServiceNow ignores a condition on a field that doesn’t exist, which would return too much. The actions ask for every field they search on and check each record they get back. If a field is missing, or a record doesn’t match, the step stops with an error instead of using the record.
Only your instance. The actions call only the instance of the connection, by path. They read ServiceNow’s paging headers only to know whether more pages follow, and never call an address from them.
When ServiceNow slows you down. Your ServiceNow admin can set a rate limit for the integration user. When it is reached, ServiceNow answers 429 Too Many Requests with a wait time. If the wait is up to a minute, Liitora waits and tries again, within the step’s timeout. ServiceNow didn’t process a request it answered with 429, so a create is safe to send again. If it keeps happening, the step fails and says so.
Errors. A failed step says what it tried to do, the HTTP status and what to check, such as a missing role. ServiceNow’s own error text is left out, because it can contain record or field names. ServiceNow answers 404 both when a record doesn’t exist and when the integration user may not see it, so the reading actions say found: false in both cases.

servicenow.get-incident

Reads one incident by sys_id or by number.

Input	Required	What it is
`sys_id`	one of the two	The incident’s `sys_id` (32 letters and digits).
`number`	one of the two	The incident number, like `INC0010001`.
`fields`	no	The fields to return. Default: `number`, `short_description`, `state`, `caller_id`, `assigned_to`, `sys_created_on` and `sys_updated_on`. `sys_id` and `number` are always returned.

Outputs: found (true or false) and incident (the fields, or null).

  - id: incident
    name: Read the incident
    uses: library/servicenow.get-incident@v1
    connections:
      servicenow: snow
    with:
      number: ${{ trigger.body.ticket }}

servicenow.find-incidents

Lists the incidents that match all your conditions, oldest first unless you choose another order.

Input	Required	What it is
`conditions`	no	Up to 10 conditions, each with a `field`, an `operator` (`=` by default, `!=`, `LIKE` for contains, `STARTSWITH` or `ENDSWITH`) and a `value`. All must hold.
`order_by`	no	The field to sort by. Default: `sys_created_on`.
`descending`	no	Sort from the highest to the lowest value, for example the newest first.
`fields`	no	The fields to return. Default: `number`, `short_description`, `state`, `caller_id`, `assigned_to` and `sys_created_on`. The fields of your conditions are always returned too.
`page_size`	no	Incidents asked for per page, 1 to 1000 (default 100).
`max_pages`	no	Pages to read at most, 1 to 100 (default 10).
`max_items`	no	Incidents to return at most, 1 to 10000 (default 1000).

Outputs: incidents (the list), count, pages (pages read), total (the total ServiceNow reported, or null; it can include incidents the integration user may not read) and truncated.

  - id: open_network
    name: Find open network incidents
    uses: library/servicenow.find-incidents@v1
    connections:
      servicenow: snow
    with:
      conditions:
        - { field: active, value: "true" }
        - { field: category, value: network }
      descending: true
      max_items: 50

Actions that change data

These actions each change one record, or order one item. They share these rules:

One at a time. Each one changes one record, named by its sys_id or number. There is no wildcard and no list, so a mistake can’t reach more than one record.
Only the fields you give. An update changes only the fields you name. System fields (sys_...) are set by ServiceNow and are refused.
Dry runs and test runs change nothing. In a dry run, Liitora holds back the change and logs it as “would have sent”. The step succeeds with dry_run: true and status: dry_run. A test run that uses a production connection holds it back the same way. A lookup by number before the change still runs for real.
A person approves it first. Like every workflow, a version that uses these actions runs for real only after an admin approves it. See Approve a workflow.
Running it again. An update or a note sent again changes the record again: a second note is a second entry. A create sent again creates a second incident, unless you use skip_if_exists. An order sent again orders again.
Errors. If ServiceNow refuses, the step fails and names the role to check. A business rule or data policy on your instance can also refuse a change. A record that doesn’t exist fails the step too, so a mistyped number never looks like success.

servicenow.create-incident

Creates one incident.

Input	Required	What it is
`short_description`	yes	The incident’s short description.
`caller`	no	The `sys_id` of the user who reports it. Find it with `servicenow.find-user-by-email`.
`assigned_to`	no	The `sys_id` of the user to assign it to.
`work_note`	no	A first work note, which only people working on the incident see.
`comment`	no	A first additional comment. Everyone who can see the incident sees it, including the caller.
`fields`	no	Other fields by system name, like `impact`, `urgency`, `category` or `assignment_group`. Set `impact` and `urgency` rather than `priority`: ServiceNow works the priority out from them.
`skip_if_exists`	no	A `field` and a `value`, like `correlation_id` and your own ticket ID. If an incident with that value exists, nothing is created and its number is returned.

Outputs: created, status (created, already_exists or dry_run), sys_id, number and dry_run.

Use skip_if_exists whenever the same event can reach the workflow twice, for example from a webhook that is sent again. Without it, every run creates a new incident.

  - id: open
    name: Open an incident
    uses: library/servicenow.create-incident@v1
    connections:
      servicenow: snow
    with:
      short_description: ${{ trigger.body.summary }}
      caller: ${{ steps.caller.outputs.users[0].sys_id }}
      fields:
        impact: 2
        urgency: 2
        correlation_id: ${{ trigger.body.alert_id }}
      skip_if_exists:
        field: correlation_id
        value: ${{ trigger.body.alert_id }}

servicenow.update-incident

Changes the fields you give on one incident.

Input	Required	What it is
`sys_id`	one of the two	The incident’s `sys_id`.
`number`	one of the two	The incident number. The action reads the incident first to find its `sys_id`.
`fields`	yes	The fields to change, like `state`, `assigned_to` or `urgency`, as database values.

Outputs: updated, status (updated or dry_run), sys_id, number and dry_run.

To resolve or close an incident, your instance usually needs more fields, such as a resolution code and notes. Their names and values depend on your instance, so check a resolved incident in ServiceNow first.

servicenow.add-note

Adds a work note or an additional comment to one incident, request or requested item. Each note is a new entry in the record’s activity history.

Input	Required	What it is
`table`	no	`incident` (default), `sc_request` for a request or `sc_req_item` for a requested item.
`sys_id`	one of the two	The record’s `sys_id`.
`number`	one of the two	The record’s number, like `INC0010001` or `RITM0010001`.
`text`	yes	The note.
`visibility`	no	`work_note` (default): only people working on the record see it. `comment`: everyone who can see the record sees it, including the caller, and your instance may email it to them.

Outputs: added, status (added or dry_run), sys_id, number, visibility and dry_run.

Keep internal details in work notes. Write a comment only when the caller should read it.

servicenow.create-request

Orders one item from your Service Catalog. ServiceNow creates a request and a requested item, and runs the item’s own process, such as approvals and tasks.

Input	Required	What it is
`catalog_item`	yes	The `sys_id` of the catalog item. You find it on the item’s record in ServiceNow.
`quantity`	no	How many to order, 1 to 1000 (default 1).
`requested_for`	no	The `sys_id` of the user the request is for. Without it, the request is for the integration user.
`variables`	no	The answers on the item’s order form, by variable name. Fill at least every mandatory variable.

Outputs: created, status (created or dry_run), request_number (like REQ0010001), request_id, item_number, item_sys_id, item_table and dry_run.

Ordering for someone else works only if your instance allows the integration user to do that. Your ServiceNow admin decides it with the glide.sc.req_for.roles settings. If your instance uses two-step checkout, where an order first goes into a cart, the step fails and says so, because no request was created.

  - id: laptop
    name: Order a laptop for the new starter
    uses: library/servicenow.create-request@v1
    connections:
      servicenow: snow
    with:
      catalog_item: ${{ vars.laptop_item_sys_id }}
      requested_for: ${{ steps.starter.outputs.users[0].sys_id }}
      variables:
        model: standard

servicenow.get-request

Reads one request or requested item by sys_id or by number.

Input	Required	What it is
`table`	no	`sc_request` (default) for a request, or `sc_req_item` for a requested item.
`sys_id`	one of the two	The record’s `sys_id`.
`number`	one of the two	The record’s number, like `REQ0010001` or `RITM0010001`.
`fields`	no	The fields to return. Default: `number`, `short_description`, `state`, `sys_created_on` and `sys_updated_on`.

Outputs: found, table and request (the fields, or null).

servicenow.update-request

Changes the fields you give on one request or requested item.

Input	Required	What it is
`table`	no	`sc_request` (default) or `sc_req_item`.
`sys_id`	one of the two	The record’s `sys_id`.
`number`	one of the two	The record’s number. The action reads the record first to find its `sys_id`.
`fields`	yes	The fields to change, as database values.

Outputs: updated, status (updated or dry_run), table, sys_id, number and dry_run.

servicenow.find-user-by-email

Finds the users with one email address. ServiceNow doesn’t keep email addresses unique, so two users can share one.

Input	Required	What it is
`email`	yes	The email address, like `ada@example.com`. It is compared without case.
`active_only`	no	Only active users (default true).
`fields`	no	The user fields to return. Default: `user_name`, `name`, `email` and `active`.
`max_results`	no	Users to return at most, 1 to 50 (default 10).

Outputs: found, unique (exactly one user has the address), count, users and truncated.

Check unique before you use users[0], for example with if: ${{ steps.caller.outputs.unique }}, so a shared address never picks the wrong person.

Your data

What these actions return is stored with the run, like every step’s output, and deleted with the run log after your plan’s retention. Notes, comments and incidents you create stay in your ServiceNow instance, in the record’s history, so write only what your process needs. See Read run logs and Data privacy and GDPR.

Sources

Written from ServiceNow’s own documentation: