TestingOps.ai

Low-code platforms · Native connection

ServiceNow and TestingOps: test context from your instance, defects back to it

TestingOps reads what your instance already says about a service, from Agile stories and incidents to catalog variables, UI policies and existing ATF tests, and gives its AI test agents that context for new test cases.

  • Native connection
  • Available
Request a demo ServiceNow CI/CD API reference
Connection
Native connection
Writes back
Within what you allow
Last checked
7 Nov 2026

In short

ServiceNow and TestingOps in short

The ServiceNow connection reads your instance through the Table API with an integration user or OAuth client credentials: records such as stories, incidents and demands become requirements, while knowledge articles, catalog items, the tables of a scoped application and ATF suites become knowledge-base sections.

Agents search that context when they write test cases, for example to cover a catalog item's mandatory variables and UI policies, and the ATF sections tell them what is already automated.

TestingOps writes to the instance in two ways only, both started by a person: a defect filed as an incident or rm_defect record, and a run of a whole ATF suite on the instance's own ATF runner.

What it does

What it does for your testing

  1. 1

    Catalog rules become form test cases

    Input
    A catalog item, record producer or order guide with its variables, variable sets, catalog UI policies and client script names
    TestingOps
    Lists the variables in order with type, mandatory, read-only, default, reference, format and choices, and writes each UI policy as a readable condition with its effects
    Output
    Context for cases that check which variables become mandatory, hidden, read-only or cleared for which answers
  2. 2

    Scoped app tables become field and rule context

    Input
    The tables of an x_ scoped application, or a single table
    TestingOps
    Reads dictionary fields and choices, UI policies with their actions, business rules with timing, operations and filter condition, client script names and Flow Designer flows with their ordered actions
    Output
    Sections agents use to plan cases for required fields, choice lists and the conditions business rules react to
  3. 3

    Stories and incidents become requirements

    Input
    Records of rm_story, rm_epic, incident, problem, change_request, dmn_demand and the other supported tables, optionally narrowed by an encoded query
    TestingOps
    Stores number, short description, description, acceptance criteria, state and priority as requirements of the project
    Output
    Test cases that trace back to the ServiceNow record number
  4. 4

    ATF suites show what is already automated

    Input
    An ATF suite with its tests, active steps and step inputs
    TestingOps
    Writes each test with its steps and last result, marked as covered by automation, and can start the whole suite on the instance
    Output
    New cases that fill gaps instead of repeating ATF tests, and the suite's results on the link

Step by step

How it works

  1. Connect your instanceUnder Integrations → Platforms → Low-code platforms → ServiceNow, enter the instance address and sign in with an integration user and password (Basic) or OAuth client credentials. Test connection lists the record tables, knowledge bases, catalogs, scoped applications and ATF suites the user can see.
  2. Link sources to a projectIn the project's Knowledge tab, add a source under Low-code platforms: pick one from the list, or paste a filtered list link, a record, a catalog item, a knowledge article or an ATF suite.
  3. SyncSync now reads the source, and automatic syncs follow (hourly by default). Records become requirements, the other kinds become knowledge-base sections, and sections whose source did not change are not rewritten.
  4. Agents write test casesAgents and AI case generation search the requirements and sections when they write cases. The cases run as AI-executed steps on your execution provider.
  5. Report back to the instanceOn a defect, Report to… creates a record in ServiceNow. On an ATF suite link, Run suite starts the suite in ServiceNow and shows its result when it finishes.

Business rule and client script bodies are not read: they appear by name, timing and condition. Flow Designer flows appear as their ordered actions, without step inputs.

Connect

Setup

  1. In ServiceNow, create an integration user, or register an OAuth client and allow the client credentials grant on the instance. For ATF runs, give the user the sn_cicd.sys_ci_automation role.
  2. In TestingOps, open Integrations → Platforms → Low-code platforms → ServiceNow, enter the instance address (https://company.service-now.com), choose the sign-in and enter the user name or client ID and the password or client secret. Select Test connection, then Save.
  3. In the project's Knowledge tab, select Add source under Low-code platforms and pick a source, or paste a ServiceNow link: a filtered list, a record, a catalog item, a knowledge article or an ATF suite.
  4. Select Sync now. On an ATF suite link, select Run suite to run the suite in ServiceNow and see its result on the link.

Documentation: ServiceNow CI/CD API reference

Where you connect it in TestingOps: Integrations → Platforms → Low-code platforms → ServiceNow

Use cases

Use cases

Test a new catalog item before it goes live

Trigger
A team links a catalog item or a whole service catalog
Uses
Variables in order, variable sets, choices, catalog UI policies and client script names
Agent activity
Plans cases for each mandatory variable and for each UI policy condition that shows, hides, locks or clears a variable
Result
Draft cases tied to the catalog item, ready for review
Condition
Client script logic is not read; behaviour that only a script implements has to be confirmed in the portal

Fill the gaps around an ATF suite

Trigger
An ATF suite is linked to the project
Uses
The suite's tests, active steps, step inputs and last results
Agent activity
Treats what the suite covers as automated and writes cases for what it leaves out
Result
Cases that complement the suite instead of repeating it
Condition
Only whole suites can be started from TestingOps, not single ATF tests

Turn incidents into regression cases

Trigger
A link to incident or problem records narrowed by an encoded query, for example one assignment group
Uses
Up to 300 of the most recently updated matching records with description, state and priority
Agent activity
Uses the reported behaviour as requirements when it writes regression cases
Result
Cases that trace back to the incident or problem numbers
Condition
A filter that contains javascript: is refused

File findings where the service desk works

Trigger
A TestingOps run produces a defect
Uses
A ServiceNow link of the same project
Agent activity
None: a person sends the defect from its detail view with Report to…
Result
An incident, or an rm_defect record when the link points to Agile records, with the defect's title and description
Condition
The integration user must be allowed to create records in that table

Capabilities

Capabilities and limits

What is read

  • Records of rm_story, rm_epic, rm_defect, rm_enhancement, incident, problem, change_request and dmn_demand: number, short description, description, acceptance criteria, state, priority and last update; most recently updated first, up to 300 per sync, optionally narrowed by an encoded query
  • Published knowledge articles from a knowledge base or by KB number, the latest published version of each
  • Catalog items, record producers and order guides: variables in order (including variable sets) with type, mandatory, read-only, default, reference, format, help text and choices; catalog UI policies with readable conditions and effects; catalog client script names and types
  • Scoped applications (x_ scopes) or single tables: dictionary fields with type, length, mandatory, read-only, reference, default and choices; UI policies and their actions; business rules with timing, operations and filter condition; client script names; the scope's catalog items; Flow Designer flows with their ordered actions
  • ATF suites: tests in order, active steps with their input values, and the last result of each test

What is produced

  • Requirements in the project's knowledge base, one per record
  • Knowledge-base sections for articles, catalog items, tables, flows and ATF tests; ATF sections tell agents not to duplicate that automation
  • ATF suite run results on the link: status, pass, fail, error and skip counts, and each test's result with a link to ServiceNow

Where it can write

  • A record in incident, or in rm_defect when the link points to Agile records (stories, epics, defects or enhancements), when a person selects Report to… on a defect
  • A run of a whole ATF suite on the instance's own ATF runner when a person selects Run suite; TestingOps reads the outcome and writes nothing back to ATF
  • Never changed: tables, dictionary entries, catalog items, knowledge articles, flows and ATF definitions

How it connects

  • ServiceNow Table API, signed in with an integration user and password (Basic) or OAuth 2.0 client credentials registered on your instance
  • ServiceNow CI/CD API for ATF suite runs

Account and permissions

  • An integration user, or an OAuth client registered on your instance; for OAuth the instance must allow the client credentials grant (glide.oauth.inbound.client.credential.grant_type.enabled)
  • Read access to the tables you link, and the right to create records in incident or rm_defect if you file defects
  • For ATF runs: the sn_cicd.sys_ci_automation role (or admin) and ATF enabled on the instance (sn_atf.runner.enabled, sn_atf.schedule.enabled)

Limits

  • Business rule and client script bodies are not read, and Flow Designer flows appear without their step inputs
  • Up to 300 records per sync, 200 sections per source, 12,000 characters per section and 100 tables per application scope
  • The application list offers custom scoped applications (x_ scopes) only
  • Only whole ATF suites run, not single tests; UI steps need a client test runner on the instance (scheduled, headless or cloud), otherwise the suite waits
  • ATF results stay on the TestingOps link; they are not merged into TestingOps run results
  • Agents work from the synced copy: there is no live lookup or update of ServiceNow records by agents
  • The instance's model reaches agents as searchable text; structured model facts and the model-coverage list are built only for Mendix

Example

Example: how a team uses it

Illustrative scenario, not a customer story.

A service desk team links its laptop request catalog item and the ATF suite that orders the standard model. The item's section shows a catalog UI policy that makes Justification mandatory when Laptop type is Developer.

An agent sees that the suite covers only the standard order, so it drafts cases for a developer laptop with and without a justification and leaves the standard order to ATF. When a run finds a defect, Report to… files it as an incident.

Frequently asked questions

Can TestingOps run our ServiceNow ATF tests?

It can start a whole ATF suite through ServiceNow's CI/CD API. The suite runs on your instance's own ATF runner, and TestingOps shows the status, the pass, fail, error and skip counts and each test's result with a link to ServiceNow. Single tests cannot be started, and UI steps need a client test runner on the instance.

Does TestingOps create ATF tests?

No. It reads existing ATF suites so agents know what is already automated, and agents write TestingOps test cases that run as AI-executed steps on your execution provider. Nothing is created in ATF.

What does TestingOps write to our instance?

Two things, both started by a person: a defect record when someone selects Report to… (incident by default, rm_defect for links to Agile records), and an ATF suite run when someone selects Run suite. Tables, catalog items, knowledge articles, flows and ATF definitions are never changed.

Does TestingOps read business rule and client script code?

No. Business rules appear with their name, timing, operations and filter condition, client scripts with their name and type. Behaviour that only a script implements is not visible to agents and has to be confirmed in the running instance.

Basic or OAuth: which sign-in should we use?

Either works. Basic uses an integration user and password; OAuth uses client credentials registered on your instance, which must allow the client credentials grant. TestingOps reads only what that user or client may read.

Can agents look up ServiceNow records while they work?

They search the copy in the project's knowledge base, refreshed on Sync now and on the automatic syncs. Agents do not query or update ServiceNow records live.

Next step

See which parts of your instance give agents the most to work with: request a demo and bring a sub-production instance with one catalog item and one ATF suite.

Request a demoMore low-code integrations