ServiceNow

Deploy Atomicwork's AI Workforce on top of your ServiceNow instance — AI coworkers that deflect, automate, and resolve requests from level 1 through level 3.

At a glance

What ServiceNow is	An IT and employee service management platform where your service teams manage tickets, catalog, and knowledge.
What the integration does	Connects Atomicwork to your ServiceNow instance and keeps tickets in sync, so your AI coworkers and human agents can work the same tickets across both systems — deflecting level 1, automating level 2, and accelerating level 3.
Modules supported	ITSM and HRSD.
ServiceNow versions	All releases after Washington 2024.
Authentication	OAuth 2.0. The integration connects through a dedicated ServiceNow user you create for the bridge, granted the required roles. Optionally, to have an AI coworker act under its own identity, you create another ServiceNow user for it with the permissions its work needs.
Configured in	Atomicwork → Settings > App store > ServiceNow
Access required	Org admin on Atomicwork; a ServiceNow admin to create the users and grant their roles.

Overview

The ServiceNow integration connects Atomicwork to your existing ServiceNow instance so your AI Workforce, Atomicwork's AI coworkers, can work directly on ServiceNow tickets. Employees get help where they already work, in Slack, Microsoft Teams, and the portal, and AI coworkers deflect, automate, and resolve requests across level 1, level 2, and level 3, taking real work off your agents' plates rather than just deflecting the easy ones.

In practice, an employee raises a question or request in Slack, Teams, or the portal, and Atom (the Universal AI Coworker) handles the level 1 ones on the spot, whether that means answering from your knowledge, resetting a password, or checking a leave balance.

When a request needs more, Atomicwork creates a ticket, either an incident or a service request, and mirrors it in ServiceNow. The right specialized coworker takes it from there, based on what the request needs: an IGA coworker for access that requires approval and provisioning, a Cloud Ops coworker for a cloud incident. Humans stay in the loop throughout, working in ServiceNow, with comments, attachments, status changes, and the fields that came from the ServiceNow catalog item flowing two-way the whole time.

Because your teams keep operating in ServiceNow, your existing workflows, assignment rules, and SLA policies stay intact.

What syncs, and how

Some objects sync the same way across all modules. Catalog items and agents are module-specific, and ticket sync differs between ITSM and HRSD.

Synced across all modules (one-way, ServiceNow → Atomicwork)

• Users — all active users in ServiceNow.
• Knowledge articles — synced through the knowledge connector (Published articles only).
• CMDB assets (coming soon) — configuration and asset records from ServiceNow's CMDB.

Catalog items (one-way, ServiceNow → Atomicwork)

Catalog items are module-specific:

• ITSM — requestable services and their form variables.
• HRSD — catalogs from the sn_hr_core_service table.

Agents and agent groups (one-way, ServiceNow → Atomicwork)

• ITSM — users in ServiceNow groups with the itil role sync as Workspace Agents, and users in groups with the itil_admin role sync as Workspace Admins.
• HRSD — not synced yet (on the roadmap).

Note: Everything above syncs one-way. Changes made to these objects in Atomicwork don't push back to ServiceNow.

Tickets (two-way, near real time)

• ITSM — incidents and service request items sync in both directions, including comments (public and internal work notes), field updates, and attachments.
• HRSD — a service request raised in Atomicwork is created as an HR case in ServiceNow, and comments (public and internal), field updates, and attachments sync in both directions.

The fields that sync two-way are the ones that came from ServiceNow — the variables on the synced ServiceNow catalog item, and the native ticket fields. Fields you add in Atomicwork aren't part of the ServiceNow record, so they stay in Atomicwork. And for a variable that had to be converted to another type on import, an update made in Atomicwork doesn't reach ServiceNow — see Catalog variables.

A synced ticket shows a banner in Atomicwork linking to the corresponding ServiceNow record:

Before you begin

Important: When you link an Atomicwork workspace to a ServiceNow application, any service catalogs you created in Atomicwork for that workspace are replaced by the catalog synced from ServiceNow. Move any catalogs you want to keep into ServiceNow before you link.

You need a ServiceNow admin or security_admin to create the integration accounts, grant their roles, and create the OAuth endpoint, and an Org admin on Atomicwork to authorize and link.

Note: Don't have a ServiceNow instance and just want to try this out? Create a free one at the ServiceNow developer portal. Sign in, or select New user? Get a ServiceNow ID to create an account, and you'll land on a developer instance you can use for the steps below.

Connect ServiceNow

Atomicwork connects to ServiceNow over OAuth, and an OAuth connection carries the permissions of whoever authorizes it. So you connect using dedicated ServiceNow accounts: a bridge account for the integration itself, and, optionally, a coworker account for each AI coworker you want to act under its own identity. This keeps the sync's broad access off any individual's identity and gives each coworker its own boundaries and audit trail.

Step 1: Create the accounts and grant their roles

Create a bridge account (required). We also recommend creating a coworker account for each AI coworker, so its actions show under its own name. Grant each the roles below.

Bridge account — handles the sync. Grant:

• snc_platform_rest_api_access — lets the account use the REST API. Nothing works without it.
• itil — read and update the incidents, requests, and request items Atomicwork mirrors.
• approval_admin — action approvals from Atomicwork (see Approvals).
• x_atomicwork.bridge — a custom role you create in ServiceNow. Give it the ACLs listed in Appendix: what the bridge reads, all read-only.

Add sn_hr_core.case_writer only if you're also connecting the HRSD (HR) module.

Coworker account (optional, but recommended) — create one for each AI coworker so its comments and actions in ServiceNow show under that coworker's name. If you don't connect an account for a coworker, its comments and actions post under the bridge account instead. Grant it:

Note: Even with a coworker account connected, if it lacks permission for a specific action, the bridge account completes that action instead (attributed to the bridge account). Don't give a coworker account the x_atomicwork.bridge role.

Step 2: Create the OAuth application

One OAuth application serves every account. In ServiceNow, click All in the top navigation, type Application Registry, and open it. Click New, then select [Deprecated UI] Create an OAuth API endpoint for external clients. (Only the UI is deprecated; the functionality is identical.)

Fill out the record:

Click Submit. Re-open the record, copy the Client ID and Client Secret (click the padlock to reveal the secret), and send them to Atomicwork over a secure channel.

Step 3: Connect in Atomicwork

1. In Atomicwork, go to Settings > App store > ServiceNow.

   

2. Start the connection, enter your ServiceNow instance URL, client ID, and client secret. When ServiceNow asks you to sign in, sign in as the bridge account.

   

   

Use a private or incognito window. If you're already signed into ServiceNow, it authorizes as you without asking, and the setup will look like it worked. Sign in explicitly as the bridge account, then confirm the connected account shown in Atomicwork. If it shows your name, disconnect and redo it.

Step 4: Link ServiceNow applications to Atomicwork workspaces

Map your Atomicwork workspaces to the corresponding ServiceNow applications. The integration supports a one-to-one mapping between an Atomicwork workspace and a ServiceNow module (such as ITSM).

Important: Linking replaces any service catalogs you created in Atomicwork for that workspace with the catalog synced from ServiceNow. Move any catalogs you want to keep into ServiceNow before you link.

1. In Atomicwork, go to Settings > App store > ServiceNow. The page confirms who connected the instance and when.

   

2. Click Manage on the Link ServiceNow applications to Atomicwork card.

3. Click Link application in the top-right corner.

4. Select the Atomicwork workspace (for example, "IT Support") and the corresponding ServiceNow application (such as "ITSM").

5. Click Save. The linked pair now appears in your active connections list.

   

Step 5: Connect AI coworker identities

On the ServiceNow page, open Connect AI coworker identities (click Manage). Click Connect next to a coworker and sign in as that coworker's account. Repeat for each coworker; the ServiceNow user and Status columns confirm which account each one is connected as.

Use a private or incognito window here too, so each coworker connects as its own account and not as you. Confirm the account shown for each coworker after connecting.

Sync knowledge

The Knowledge Connector syncs your ServiceNow Knowledge Base articles so Atom can answer employee questions.

1. In Atomicwork, navigate to Settings > Knowledge under Atom AI.
2. Click Add folder at the top right.
3. Select ServiceNow as your knowledge source. This shows all knowledge bases in your connected instance, with categories and subcategories as folders.
4. Select the knowledge bases, categories, or articles to ingest.
5. Click Save to begin ingestion.

Personal connections

Separate from the integration accounts, each end user and agent establishes a personal connection so their own actions (such as posting comments under their own name) are attributed to them.

End users can connect either during a request (Atom shows a Connect to ServiceNow button when they raise a request without an active connection) or from Settings > Connections in the portal.

Agents can connect from Settings > Connections, or from a ticket — if an agent tries to comment without a personal connection, the comment box stays locked and shows a Connect banner; connecting unlocks it and attributes replies to their ServiceNow user.

Notifications

• Option 1 — Atomicwork handles all notifications (recommended): Atomicwork sends all email, Slack, and Teams notifications; disable native ServiceNow email notifications. All links point back to Atomicwork.
• Option 2 — Split notifications: ServiceNow keeps sending native email notifications; Atomicwork sends Slack and Teams. Links point to different platforms depending on channel.

Assignment

Your existing assignment workflow won't work as-is. A coworker works the ticket first, so a human isn't immediately assigned to it — assignment rules that expect a human owner from the moment a ticket is created need to be updated before you go live.

Approvals

When an approval is triggered in ServiceNow, it surfaces in Atomicwork so the approver can act on it in Slack or the portal, and their decision syncs back to ServiceNow. Actioning approvals from Atomicwork requires the approval_admin role on the bridge account (see Step 1).

Behaviors and limits

• Object mapping. Incidents map 1:1 to Atomicwork tickets. Each ServiceNow Request Item maps 1:1 to a ticket — the parent Service Request hierarchy is stored in the backend but not shown in the UI.
• Catalog hierarchy. ServiceNow's three levels (Catalog → Category → Subcategory) collapse to two levels (Category → Service catalogs) in Atomicwork. Subcategory data is preserved in the backend but not displayed.
• Catalog variables. Natively supported variable types import as-is and stay editable. Unsupported types, such as reference fields, convert to plain-text fields. A converted variable stops syncing back — once its type changes on import, an update to that field in Atomicwork doesn't reach ServiceNow. Dynamic form behavior (UI policies, client scripts, scripted reference qualifiers, catalog client scripts) doesn't transfer, so those fields render statically.
• Knowledge. Only Published articles are imported; Draft and Retired are skipped. Articles past their valid-to (retirement) date are automatically soft-deleted in Atomicwork.
• Access control. ServiceNow user criteria on knowledge and catalog items is translated into Atomicwork user segments on import, so the same audiences apply. ServiceNow access control lists (ACLs) — the table-, record-, and field-level rules that govern who can read or edit data inside ServiceNow — are not carried over.
• Coworker permission fallback. If a coworker account lacks access for an action, the bridge account completes it instead, attributed to Atomicwork Bridge. Scope coworkers through Atomicwork rather than relying on ServiceNow to refuse the action.
• Incidents are created as generic intake records (they don't use a catalog structure in ServiceNow).
• Field sync scope. Two-way field sync covers the fields that originate in ServiceNow — the variables on the synced catalog item and the native ticket fields. Fields added in Atomicwork don't exist on the ServiceNow record and don't push to it, and updates to a converted variable don't push back either.
• One-way objects don't push back. Changes to users, agents, agent groups, or catalog items in Atomicwork don't sync to ServiceNow.
• Sync failures are surfaced directly on the ticket in Atomicwork, in the activity logs.

Unsupported features

ServiceNow is highly configurable across many layers: catalog visibility and behavior, form logic (UI policies and client scripts), business rules and flows, access control (ACLs), SLAs, and assignment and notification rules. Atomicwork doesn't replicate all of that as-is. The table below lists the specific constructs that aren't covered; if your workflows rely on them, continue to manage them in ServiceNow.

Troubleshooting

Appendix: what the bridge reads

Create the x_atomicwork.bridge custom role in ServiceNow and give it read-only ACLs on the tables below.

The audience tables are the largest group: Atomicwork reads your visibility rules once and reproduces them as user segments, rather than checking each person against each item at query time. Access covered by the itil role (tickets, users, groups, attachments, and the departments, companies, and locations referenced by audience rules) isn't repeated here.

Related

• Setting up an AI Coworker
• Trusted knowledge for employee questions
• Stay updated with notifications
• Need help? Contact support@atomicwork.com for assistance with your ServiceNow integration.