The Atomicwork-ServiceNow integration allows you to use Atomicwork as the AI and experience layer for your employees while maintaining ServiceNow as your system of record. Employees can find answers and submit requests through Slack, Microsoft Teams, the Atomicwork portal, or email. Tickets, comments, and status changes sync bi-directionally in near real time so your agents can work from either platform. This integration focuses on the IT Service Management (ITSM) module, specifically incidents, service requests, knowledge bases, and the service catalog.
How the integration works
ServiceNow remains the source of truth for users, agents, groups, and service catalog items. These objects flow one-way from ServiceNow into Atomicwork.
Changes made to users, agents, agent groups or service catalog items in Atomicwork do not push back to ServiceNow.
Two-way sync is reserved for tickets (incidents and service requests), comments (public and internal work notes), and status changes. This ensures that actions taken by an agent or AI Coworker in one system show up in the other in near real time.
The integration anchors on two ServiceNow roles for agent definition:
itil: Maps to Workspace Agent in Atomicwork.
itil_admin: Maps to Workspace Admin in Atomicwork.
Because some ServiceNow concepts do not have a direct counterpart in Atomicwork, the integration maps them as follows:
Service requests: ServiceNow models service requests across a parent Service Request and child Request Items. Atomicwork does not use a two-level model, so the integration maps each ServiceNow Request Item 1:1 to an Atomicwork ticket. The parent hierarchy is recorded in the backend but is not exposed in the user interface.
Incidents: Mapped 1:1.
Service catalog: ServiceNow's three-level hierarchy (Catalog, Category, Subcategory) collapses to a two-level hierarchy (Category, Service catalogs) in Atomicwork. The top-level ServiceNow catalog appears as the Technical / Service Catalog container in Atomicwork.
Connecting ServiceNow removes any service catalogs created in Atomicwork. Only items synced from ServiceNow will be available.
Move any catalogs you want to keep into ServiceNow before connecting.
Connect ServiceNow to Atomicwork
To establish the integration, you must configure two levels of OAuth connection:
Admin connection: Set this up once from the Atomicwork App Store to authorize Atomicwork to communicate with your ServiceNow instance.
Personal connection: Every end user and agent must establish a personal connection so ServiceNow can attribute actions, such as posting comments, to the correct user. If a user does not have an active personal connection, the comment box in Atomicwork is blocked.
Users and agents can establish their personal connection in two ways:
In-line: Slack, Microsoft Teams, or the portal prompts users automatically the first time they perform an action that requires authentication.
Proactively: Users can go to Settings > Connections in the Atomicwork portal to connect their account.
Syncing ServiceNow knowledge articles
Atomicwork syncs ServiceNow knowledge base articles through the knowledge connector. To learn more about managing knowledge sources, see how to add and organize knowledge for your Assistant.
When configuring the knowledge connector, keep the following in mind:
You can select specific knowledge bases, categories, and subcategories to sync into Atomicwork, from the folder picker.
Atomicwork only imports articles in the Published state. Draft and Retired articles are skipped.
Articles that pass their valid-to (retirement) date are automatically soft-deleted in Atomicwork.
Atomicwork does not use ServiceNow user criteria or Access Control Lists (ACLs). You must manage access control using Atomicwork's user segments.
When an employee asks a question in Slack, Teams, or the portal, Atom searches for the correct knowledge base/article and provides a grounded response with a direct link back to the source article in ServiceNow.
Managing synced service catalogs and tickets
When a ServiceNow catalog item is synced into Atomicwork, the variables on the item are imported as request attributes in Atomicwork. The import behavior depends on the variable type:
Natively supported variables import as-is and remain fully editable.
Unsupported variables convert to plain-text fields.
Dynamic-form behaviors, such as UI policies, client scripts, scripted reference qualifiers, and catalog client scripts, do not preserve their behaviour. Fields render statically in Atomicwork.
For incidents and service requests, conversation history, comments, field updates, and status changes sync bi-directionally in near real time. If a sync operation fails, the error is surfaced directly on the ticket in Atomicwork.
Understanding request assignment
Request assignment depends on your AI Workforce configuration:
With AI Coworkers: Assignment is driven by the instructions configured on the AI Coworker.
Without AI Coworkers: Assignment works through your existing ServiceNow workflows or Atomicwork's native assignment workflows. For more details on request mechanics, see assigning and working on requests.
Configuring request notifications
During initial setup, you must choose how request notifications are delivered:
Option 1: Atomicwork handles all notifications. Atomicwork sends all email, Slack, and Microsoft Teams notifications. You must disable ServiceNow's native email notifications in ServiceNow. All links in these notifications point to Atomicwork.
Option 2: Split delivery. ServiceNow continues to send its native email notifications, while Atomicwork sends Slack and Microsoft Teams notifications. Slack and Teams notifications contain Atomicwork links, and email notifications contain ServiceNow links.
Unsupported ServiceNow features
Certain ServiceNow modules and configurations are not directly supported in Atomicwork with this integration. If your workflows rely on these features, you must continue to manage them directly in ServiceNow.
ServiceNow construct | What it is | Behavior with the integration |
HR, Finance, CSM, and other non-ITSM modules | ServiceNow modules outside ITSM. They use their own record types — HR Cases, financial requests, customer service cases — rather than incidents and service requests. | Not covered. Continue to manage these workflows in ServiceNow. |
Custom agent roles | ServiceNow roles beyond | Only |
Catalog subcategories | The third level of ServiceNow's catalog hierarchy (Catalog → Category → Subcategory). | Subcategory data is preserved in the Atomicwork backend so the mapping isn't lost, but it isn't displayed in the catalog UI. |
Incident catalogs and record producers | ServiceNow forms that let users raise incidents directly from the service catalog. | Not synced. Incidents in Atomicwork are created as generic intake records. |
Service request parent records | The parent Service Request that groups multiple Request Items in ServiceNow (for example, an "Onboarding" parent with laptop, app access, and desk children). | Each Request Item is mapped 1:1 to a ticket in Atomicwork. The parent hierarchy is stored in the backend but isn't shown in the UI. |
Order guides | ServiceNow's mechanism for bundling multiple catalog items into a single guided ordering experience. | Not synced. Each catalog item appears as a standalone request in Atomicwork. |
Workflows and fulfillment automation | Server-side Flow Designer flows, workflow editor workflows, and automated task assignment logic in ServiceNow. | Not mirrored in Atomicwork. They continue to run inside ServiceNow on the synced records. |
Scripted form behavior | UI policies, catalog client scripts, scripted reference qualifiers, and other dynamic form logic in ServiceNow. | Not preserved. Atomicwork forms render statically — fields don't appear, disappear, or change based on other field values. |
Multi-language catalog content | Translated catalog item names, descriptions, and field labels in ServiceNow. | Not synced. Catalog content appears in the source language only. |
Problem and change catalogs | Customer-facing forms for raising problem or change records via the ServiceNow catalog. | Not synced. The Bridge doesn't cover problems or changes today. |
ServiceNow approval workflows | ServiceNow's approval engine — approval definitions, rules, and the | Approvals from ServiceNow are passed through to Atomicwork notifications, but the approval workflow itself isn't replicated in Atomicwork. |