Reference · built on requestConnectorWork & ticket management

ServiceNow

Incident, problem, change, and request records from a ServiceNow instance through the Table API and other inbound REST APIs.

About

ServiceNow is a platform for IT and enterprise service management. Each customer runs its own instance, and records such as incidents are rows in tables that the inbound REST APIs expose by name: the Table API, Aggregate API, Import Set API, Attachment API, and any Scripted REST API the instance defines. Access is governed by the caller's roles and by REST API ACLs.

Through Fibric, an operator reads records from the tables you name, applies an encoded query, and proposes a field update, a reassignment, or a new record for your approval. Each approved change is written down with what changed, why, and how to reverse it.

This is a reference listing. It documents what Fibric would read from ServiceNow and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Records from a named table through GET /now/table/{tableName}, filtered by sysparm_query and trimmed by sysparm_fields
  • One record through GET /now/table/{tableName}/{sys_id}, with sysparm_display_value for labels instead of stored values
  • Incidents through /api/now/table/incident, and problem, change, and request records through the same API by table name
  • Paged reads through sysparm_limit and sysparm_offset; the default sysparm_limit is 10,000 records
  • Counts and groupings through the Aggregate API, and files through the Attachment API
  • Versioned endpoints such as /api/now/v1/table/{tableName}; unversioned URIs use the latest endpoint for the instance

Proposed actions

  • Target capability: propose a field update through PATCH /now/table/{tableName}/{sys_id}
  • Target capability: propose a full record replacement through PUT /now/table/{tableName}/{sys_id}
  • Target capability: propose a new record through POST /now/table/{tableName}
  • Target capability: propose bulk loads through the Import Set API rather than row-by-row inserts

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Respond to an outage

    When monitoring fires, the operator drafts an incident record with the alert context, proposes it through POST on the incident table, and adds the incident number to the paging channel.

    With Uptime Response

  • Keep the change freeze

    During a freeze, the operator reads change records scheduled in the window and proposes a hold and a note before the change proceeds.

    With Change Freeze

  • Schedule the patch window

    Change records for patching get their planned dates checked against the maintenance calendar. The operator proposes date moves and assignments for approval.

    With Patch Window

  • Route a tenant request

    Requests logged in a request table are read by category and location. The operator proposes the assignment group and priority and leaves the reason in the record.

    With Request Routing

Requirements

  • A ServiceNow instance and a user whose roles cover every table the operator reads or writes; the Table API enforces that user's access
  • For OAuth, an admin to create an OAuth API endpoint for external clients in the Application Registry, with the OAuth 2.0 plugin active
  • The Table API base ACL enabled, since it and three other base ACLs are deactivated by default
  • Table names for the records you care about, such as incident, and an encoded query for each watch
Authentication
Basic authentication with an instance user, OAuth 2.0 through an OAuth API endpoint for external clients and oauth_token.do, or an API key once the com.glide.tokenbased_auth plugin is installed.

Limits

  • The inbound REST APIs answer requests; nothing here pushes changes, so the connector polls each table on a schedule
  • Rate limit rules restrict requests per hour per user, per role, or for all users; a 429 carries Retry-After and X-RateLimit-Rule
  • sysparm_limit defaults to 10,000 records, so large pulls are paged with sysparm_offset
  • sysparm_query_no_domain is available only to system administrators or users with the query_no_domain_table_api role

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request ServiceNow ↗

Questions and answers

Which tables can the connector read?
Any table the calling user's roles allow, named in the path: GET /now/table/{tableName}. The documentation's example updates an incident at /api/now/v1/table/incident/{sys_id}. Filtering uses sysparm_query, field selection uses sysparm_fields, and reference fields can drop their links with sysparm_exclude_reference_link.
How are rate limits set?
By rate limit rules in the sysratelimitrules table, per user, per role, or for all users, counted per hour. A single-user rule overrides role rules, which override all-user rules. Counts commit every 30 seconds. Over the limit, the instance returns 429 with Retry-After.
Which authentication methods apply?
By default the inbound REST APIs use basic authentication or OAuth. OAuth needs the OAuth 2.0 plugin and an OAuth API endpoint for external clients; tokens come from oauth_token.do. API keys and HMAC tokens are available once com.glide.tokenbased_auth is installed. MFA is not required by default for basic authentication.
Ask about ServiceNow

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.