ServiceNow

Overview

This integration syncs Knowledge Articles from a ServiceNow Knowledge Base into Leena AI's Knowledge Management (KM) module, enabling the virtual assistant to surface ServiceNow content in employee responses.

At a glance:

• What is synced. Published knowledge articles, and their attachments, from the knowledge bases selected during setup.
• What controls visibility. Optionally, each article's ServiceNow access rules — User Criteria and the roles applied directly on the article — are resolved and mirrored onto the KM article as an audience. Refer to Sync scope and supported permissions.
• What is not synced. Articles in any state other than Published, and audiences defined by scripted (advanced) User Criteria. A supported workaround for scripted criteria is documented below.
• How the connection is made. OAuth Client Credentials, using a dedicated ServiceNow service account.

Before you begin

The following are required:

• Administrator access to ServiceNow, to register an OAuth application under System OAuth → Application Registry and to configure a service account.
• A dedicated service account holding the roles listed under Service account requirements. A dedicated account, rather than a personal administrator login, keeps the integration stable across staff changes and simple to audit.
• The ServiceNow instance URL, for example https://<instance>.service-now.com.
• Access to the KM dashboard, with permission to configure connectors under Settings → Integrations.

Decide during setup whether ServiceNow access controls should be mirrored into KM. If they should, enable permission sync at configuration time and confirm the service account holds the user and criteria roles. Refer to Sync scope and supported permissions.

Service Account Requirements & Permissions

Create a dedicated service account in ServiceNow for this integration rather than reusing an existing user account. Using a dedicated service account ensures that the integration remains stable and is not affected by changes to individual user accounts (e.g., password resets, role changes, or account deactivation).

Once the service account is created, assign it the required roles. Go to User Administration → Users, select your service account user, and ensure all of the following roles are set:

Once your service account is created and the roles are assigned, proceed to the OAuth setup below.

Granting ServiceNow Access Using OAuth

1. Login to your ServiceNow account with your Service Account credentials.

2. Go to your ServiceNow developer instance and select “Application Registry” under “System OAuth”.

   

3. Click on “New” application and select the following option: “New Inbound Integration Experience”.

   

4. Select New Integrations

5. Select OAuth-Client credentials grant

   

6. Fill in the details about the new app. Select 'useraccount' under Auth scope.

6. Please note the Client ID and Client Secret from this step.
   

Leena AI Configuration

1. Go to KM Dashboard >> Settings >> Integrations >> ServiceNow.

2. Fill in the required details:

   • Client ID
   • Client Secret
   • Instance URL

3. Select the setting to move fetched articles to Published state in KM or Draft state.

4. (Optional) Select the option to fetch permissions for ServiceNow.

   

Syncing

Once the connection succeeds, knowledge articles can be synced from ServiceNow into KM.

All available knowledge bases are listed, and specific knowledge bases can be selected for sync; it is not necessary to sync every knowledge base. After the first full sync, subsequent syncs pick up new, updated, and newly published articles, together with permission changes. Sync cadence is configurable, and more than one ServiceNow connector instance may be run against the same bot — refer to Managing Multiple Instances of a Connector.

Only articles in the Published state are synced, and only attribute-based article audiences can be resolved; scripted (advanced) User Criteria cannot be synced. Refer to Sync scope and supported permissions below for the full detail and the recommended workaround.

The outcome of each run, including skipped and failed articles, is available in the sync logs. Refer to KM Sync Logs and Debugging KM Sync Logs.

Sync scope and supported permissions

Which articles are synced

Only articles in the Published state in ServiceNow are synced to Leena KM. Articles in any other state — for example Expired, Draft, or Retired — are excluded, and do not appear in KM even when they belong to a selected knowledge base. To bring an excluded article in, republish it in ServiceNow; it is picked up on the next sync.

Where an article filter has been configured on the connector, it narrows this set further. The knowledge base selection, the Published-state rule, and the article filter apply together.

Including the ServiceNow KB number in article titles

If your users search for articles by their ServiceNow KB number, Leena AI can append the article number to the title of every article it syncs from ServiceNow.

When enabled, a synced article's title becomes: <ServiceNow article title> - KB0012345

This makes the KB number searchable, because it becomes part of the article title that Knowledge Management indexes.

Behaviour

• Applies to knowledge articles only. Attachments keep their original filename as the title.
• Articles with no article number in ServiceNow are unchanged.
• The article title in ServiceNow itself is never modified. Only the title Leena AI stores is affected.
• Turning the setting on or off changes titles from the next sync onward. Titles are never double-appended.

Article filter: supported columns and conditions

A connector may be given an article filter that narrows the sync set beyond the Published-state rule and the knowledge base selection. The filter is expressed as one or more conditions on columns of the kb_knowledge table, and every article that passes the filter is synced.

Columns available for filtering

Only custom columns on kb_knowledge are surfaced as filterable. A column qualifies where its technical name begins with u_, it belongs to a base package (Global), and it was not created by the ServiceNow platform itself. Standard out-of-the-box columns — for example short_description, kb_category, or workflow_state — are not offered as filter columns. In addition to the custom columns, a built-in Valid To filter (backed by valid_to) is always available.

Supported column types and their conditions

A custom column is only surfaced where its ServiceNow internal type is one of the following. Columns of any other type — including Choice and reference (sys_id) columns — are not currently offered as filter columns; where an audience needs to be expressed on such a column, refer to Working with scripted (advanced) User Criteria or contact the Leena AI CSM.

Between takes a pair of values, inclusive on both ends.

How the filter combines with other rules

The article filter applies alongside — not instead of — the knowledge base selection and the Published-state rule. An article is synced only where it satisfies all three. Where permission sync is also enabled, the audience rules described below are applied after the filter has decided which articles to sync.

What permission sync does

Permission sync controls who can see a synced article in KM.

• When permission sync is disabled, no ServiceNow access rules are read. Each synced article is published to KM without a restricting audience, and is therefore visible to everyone the assistant serves. This is expected behaviour, and it is the most common reason an article's audience appears larger than intended.
• When permission sync is enabled, the connector resolves the set of users permitted to read each article in ServiceNow, and attaches that set as the KM article's audience.

How access is resolved

When permission sync is enabled, an article's KM audience is the set of users who satisfy all applicable ServiceNow read rules. The rules are applied together, so the resulting audience is the most restrictive combination of them:

1. Can Read and Cannot Read User Criteria on the article.
2. Can Read and Cannot Read User Criteria inherited from the parent knowledge base.
3. Roles applied directly on the article, independent of any User Criteria.
4. The article author, who always retains access.

Members of an attribute-based criterion — whether the criterion targets a role, a group, a department, a location, or a company — are fully expanded to the matching users.

1. User criteria

The type of User Criteria configured in ServiceNow determines whether its audience can be resolved:

• Attribute-based User Criteria are fully supported. Criteria that target a role, group, department, location, company, or similar attribute are resolved, and every matching user is granted or denied read access accordingly.
• Scripted (advanced) User Criteria are not supported. These criteria determine their audience through a script that ServiceNow evaluates per user at the moment of access, so membership is dynamic and is never stored as a list. Because ServiceNow exposes no interface that returns the members of a scripted criterion, the audience cannot be read or synced. Where an article combines an attribute-based criterion with a scripted one, only the attribute-based audience is synced; the scripted portion is omitted. Refer to Working with scripted (advanced) User Criteria for the recommended workaround.

2. Roles applied directly on the article

ServiceNow also permits an article to be restricted to holders of one or more roles by setting the article's Roles field directly, separately from any User Criteria. A common example is restricting an article to users holding the itil role.

The connector reads these directly applied roles, resolves them to the users who hold them, and narrows the article's audience accordingly. A user must therefore both be permitted by the article and knowledge base criteria and hold a required role in order to receive read access. In practice this produces a smaller, more precise audience than the criteria alone would.

Points to note:

• A role of public is treated as "all users" and applies no restriction, consistent with ServiceNow behaviour.
• Where a required role currently resolves to no users — for example, a role that exists but is presently assigned to nobody — the article's audience is reduced to the author only. The article is not released to a broader audience.
• Roles referenced inside a User Criterion have always been honoured. This capability additionally covers roles applied directly on the article.
• This capability is enabled per environment. Where articles are restricted by a role placed directly on the article and their KM audiences appear larger than expected, contact the Leena AI CSM to confirm it is active for the bot, and then re-sync.

ServiceNow properties that affect resolution

Two ServiceNow knowledge properties influence how access is resolved. The connector honours both, so that KM visibility matches ServiceNow:

How changes propagate

Audiences are recomputed on sync, not in real time:

• Criteria and group changes. Changes to User Criteria, to the criteria attached to a knowledge base, and to group membership are re-evaluated on the next sync, and the audience is updated in KM.
• Role membership changes. Where a user is granted or removed from a role in ServiceNow, articles restricted by that role are re-evaluated on the next sync, provided the article-level roles capability is enabled for the bot. Where it is not enabled, a role membership change alone may not trigger a re-scan until the article is otherwise updated.
• Toggling permission sync. Enabling or disabling permission sync forces a re-resolution of every existing article on the next sync, so that audiences are brought fully into line with the new setting.

Working with scripted (advanced) User Criteria

The recommended way to bring a scripted audience into KM is to express each scripted criterion as a user group whose membership is kept current by a scheduled job in ServiceNow. Once the audience is a group, it is attribute-based from KM's perspective and syncs like any other group-based criterion. No changes are required on the Leena AI side.

Checking whether the instance uses scripted criteria. A ServiceNow administrator can open the User Criteria list and filter where the Advanced field is true. Any records returned are script-based and require the treatment below.

Recommended setup. For each scripted User Criterion whose audience should appear in KM:

1. Create a user group in ServiceNow to represent the audience.
2. Add a scheduled job that runs on a regular cadence and updates the group's membership using the same logic the criterion script applies, adding users who now qualify and removing those who no longer do. ServiceNow's scheduled script execution is well suited to this, and the logic mirrors the existing criterion script.
3. On the affected articles, or on their knowledge base, add a Can Read User Criterion that targets the new group, in place of, or alongside, the scripted criterion.

On the next sync, KM resolves the group's members and applies the correct read access. As the scheduled job keeps the group current, KM access stays aligned with the intended audience over time.

Choosing a refresh cadence. Because group membership is refreshed on the job's schedule rather than evaluated live at each access, the job frequency should match how quickly the underlying attribute changes. For audiences that change infrequently, such as manager level or department, a daily or twice-daily run is usually sufficient. For faster-moving attributes, schedule the job more frequently.

Verifying and troubleshooting audiences

• Confirm the setting. Where audiences appear far larger than intended, first confirm that Fetch permissions is enabled on the connector. While it is disabled, every synced article is visible to everyone.
• Re-sync after changes. Audiences update on sync. After changing criteria, group membership, or role assignments in ServiceNow, trigger a sync, or wait for the next scheduled run, before comparing.
• Inspect a specific article. Open the article in KM and review its associated audience, which lists the resolved users. Cross-check this against the users who hold the role, or who match the criterion, in ServiceNow.
• Use the reports and logs. Audience Reports in KM and KM Sync Logs help trace how an article's audience was built, and identify articles that were skipped.
• Where an audience is smaller than expected, check for a Cannot Read criterion that excludes users, or an article role that currently resolves to few or no holders.

Troubleshooting

Connector failures surface a reason in the KM dashboard. Refer to Visibility of Reason for Failure of Connectors and Debugging KM Sync Logs.

FAQs

General and authentication

Q: What is the purpose of the ServiceNow integration?
A: It connects a ServiceNow Knowledge Base to Leena AI's Knowledge Management dashboard, so that ServiceNow knowledge articles are synced into KM and can be surfaced by the virtual assistant.

Q: Which connection method is used?
A: OAuth Client Credentials, using a dedicated ServiceNow service account. It is non-interactive, requires neither a refresh token nor a stored service-account password, and is unaffected by the ServiceNow ROPC deprecation.

Q: What is changing with authentication?
A: ServiceNow is deprecating the Resource Owner Password Credentials (ROPC) grant. Connections created earlier using the Token Based (refresh token) or Password Based methods rely on that grant, and continue to work only for as long as the instance still permits it. Those connections must be migrated to Client Credentials. Refer to the advisory at the top of this page.

Configuration

Q: How is a Client ID and Client Secret obtained?
A: In ServiceNow, go to System OAuth → Application Registry and register a new application. ServiceNow generates the Client ID and Client Secret.

Q: What details are required for setup?
A: Client ID, Client Secret, and Instance URL. No refresh token and no service-account password are required.

Syncing

Q: Is it necessary to sync every knowledge base?
A: No. All available knowledge bases are listed, and specific ones can be selected for sync.

Q: Which article statuses are synced from ServiceNow?
A: Only articles in the Published state are synced. Articles that are Expired, Draft, or otherwise not Published are excluded and do not appear in KM. Republishing an article in ServiceNow makes it eligible for the next sync.

Q: What happens to articles after they are synced?
A: Fetched articles can be configured to arrive in KM either in a directly published state or in a draft state.

Q: Are attachments synced?
A: Yes, where Download attachments is enabled on the connector. Attachments on published articles are read from ServiceNow and inherit the parent article's audience. No additional OAuth scope is required: the useraccount auth scope selected during application registration grants the application the access available to the service account, provided Limit authorization to the following APIs is left empty.

Permissions

Q: Can the permissions on ServiceNow articles be synced?
A: Yes. Enable Fetch permissions on the connector. The connector then honours the article's Can Read and Cannot Read User Criteria, the criteria inherited from the knowledge base, any roles or groups referenced inside those criteria, and any roles applied directly on the article. Each KM article's audience is built from the resolved users.

Q: After enabling permission sync, some article audiences are not coming through. Why?
A: This typically happens where the article's access is controlled by a scripted (advanced) User Criterion. Scripted criteria resolve their members through a script at access time, so the membership is never stored and cannot be read by the connector. Attribute-based User Criteria — role, group, department, location, and the like — sync as expected. To sync a scripted audience, mirror it to a group kept current by a scheduled job in ServiceNow.

Q: An article is restricted to a specific role in ServiceNow, but its KM audience appears larger than expected. What should be checked?
A: First confirm that Fetch permissions is enabled; while it is disabled, synced articles are visible to everyone. Where the restriction is a role placed directly on the article, confirm with the Leena AI CSM that the article-level roles capability is active for the bot, and then re-sync. Audiences are recomputed on every sync.

Q: Why does the audience show a list of users rather than the role or criterion name?
A: Leena AI resolves ServiceNow access into the concrete set of users who have access, and builds the audience from that set. The criterion or role definition itself is not copied into KM. Seeing resolved users — derived from the article roles, the User Criteria, and the knowledge base rules — is expected.

Q: How do role and criteria changes in ServiceNow reach KM?
A: On sync. Criteria and group membership changes are re-evaluated on each sync. Role membership changes are re-evaluated where the article-level roles capability is enabled. Enabling or disabling permission sync re-resolves every existing article on the next sync.

Q: How can it be determined whether the instance uses scripted User Criteria?
A: A ServiceNow administrator can open the User Criteria list and filter where the Advanced field is true. Any records returned are script-based.