ServiceNow Knowledge Base

​

What Flow indexes from ServiceNow Knowledge Base

ServiceNow Knowledge Base brings published ServiceNow KB articles and attachments into Flow knowledge search through the supported ServiceNow connection. A source connects and a filter count can succeed while the first sync still fails. Authorize and Run count only read kb_knowledge. The first crawl also reads mapped template article bodies, knowledge bases, User Criteria, people, groups, roles, and attachments.

​

Capabilities

• ServiceNow OAuth connect through the same integration family as ticketing
• Select the whole instance, specific knowledge bases, or individual articles to sync
• Article and attachment sync
• Scheduled and on-demand sync
• ServiceNow Knowledge access based on supported user criteria
• Explicit team or organization visibility when intentionally configured
• Advanced article body mappings for standard and custom Knowledge templates

​

Authorization model

Flow does not make an article available when it cannot safely determine who may read it. Supported access modes:

1. User Criteria
   • Primary mode.
   • Flow uses supported ServiceNow criteria to identify who can search an article.
2. Available to Team
   • Explicitly makes content available to the selected team.
   • It is not selected automatically when User Criteria cannot be used.
3. Available to Org
   • Explicitly makes content available to the organization.
   • It is not selected automatically when User Criteria cannot be used.

​

Criteria Flow can use

​

Article-level roles

Article roles can contain role IDs or names. When names are present, the integration account also needs read access to sys_user_role.sys_id and sys_user_role.name. Flow requires one exact role-name match before checking membership. A verified match to one listed role can grant the role layer even when another name is unresolved. Unresolved roles add no readers; if no role matches, access stays closed. The integration account must also be able to read kb_knowledge.roles, including an empty value when an article has no role restriction. If ServiceNow omits that field, Flow blocks access and identifies kb_knowledge.roles in the permission guidance. An omitted field is not proof that the article is unrestricted. For each User Criteria record, Flow must be able to read user, group, role, company, department, location, advanced, match_all, and active. An unreadable allow definition adds no verified readers, but a separate supported allow criterion can still grant access. An unreadable deny definition blocks access. Flow also checks that each knowledge-base rule listing is complete before using it to grant access. An incomplete access refresh retains the previous decision and reports stale access data. Knowledge-base rule links must also return their user_criteria reference; missing references withhold access, including for deny rules. The permission guidance distinguishes, for example, user_criteria.company from the person’s sys_user.company field. Flow supports the Roles field on an article in User Criteria mode. A reader must hold at least one listed role and satisfy the applicable article and knowledge-base criteria. Deny criteria still remove access. When an article has roles but no allow criteria, only verified holders of those roles receive access. Flow checks role membership for people who already exist in Flow. Missing membership evidence does not grant access. A valid returned allow membership can prove a reader even if the list is incomplete. Incomplete deny membership remains blocking. After changing roles or membership, refresh access and test both an eligible reader and an excluded reader. Flow always enforces populated article roles in User Criteria mode. It does not reproduce the ServiceNow property that disables role-based security, or special contributor and administrator bypasses. These differences can make Flow more restrictive. Explicit Available to Team and Available to Org use their configured audiences instead. The integration user must be able to read both the role and the user on role-membership rows (sys_user_has_role). An HTTP success that returns a person but omits the role is not proof of membership. Grant field-level read of both columns on the dedicated integration role. Do not grant admin or knowledge_admin.

​

Criteria Flow cannot use

In User Criteria mode, Flow grants access only to readers it can verify. Unsupported restrictions do not fall back to team or org visibility. Within a supported criterion, Match All requires every populated condition to match. When it is off, one proven condition can match even if another condition cannot be evaluated. Flow does not use this rule to assume that a deny condition is false. People whose identities cannot be uniquely matched receive no access. Their identity problem does not block independently verified readers. Multiple Can Read criteria in the same list are alternatives: a reader needs one supported match. The reader must still pass the applicable knowledge-base criteria, article criteria, article roles, and deny checks. A list containing only scripted criteria does not count as an unrestricted list. Flow does not evaluate scripts or use the other fields inside a scripted criterion to grant access. Articles with no User Criteria grant the owning team search access by default. An organization admin can turn that off in source settings. Broader Available to Team or Available to Org visibility still requires an explicit access-mode change.

​

Prerequisites

• A ServiceNow administrator or delegated platform owner who can create an OAuth application and configure scoped roles, access control list (ACL) rules, and REST API Access Policies. The OAuth application user does not need administrator privileges.
• A Flow admin who can open Integrations.
• Your ServiceNow instance URL (for example https://acme.service-now.com).

​

Prepare the provider

Use the same OAuth client-credentials setup as ServiceNow ticketing. You need a dedicated integration user, an Application Registry client with Default Grant Type set to Client Credentials, an OAuth Application User, and a Table API auth scope (now/table). Create a customer-owned integration role for the OAuth application user. Do not assign admin or knowledge_admin. Grant that role read access only to the selected knowledge bases and the supporting tables below. The kb_knowledge read rule must let the application user retrieve every article in the configured source scope. That remains true even when the application user is not an end-user reader under the article’s User Criteria. Flow reads those criteria separately and applies them to search access. Do not add the integration user to article or knowledge-base Can Read criteria only to make the crawl work. That changes the source authorization policy. Use the scoped integration role and read ACL instead. Grant least-privilege Table API reads for Knowledge crawl: Table ACLs are not the only gate. Confirm Allow access to this table via web services on each table’s Application Access tab. Confirm REST API Access Policies (sys_api_access_policy) allow Table API GET on those tables and Attachment API reads for files. A policy that blocks only a crawl table, or only the Attachment API, can let connect and Run count succeed and still fail the first sync.

​

Company, department, and location permissions

For these criteria, Flow compares reference values on the criterion with company, department, and location on the matching ServiceNow user. Grant read access to the fields used by your criteria on both user_criteria and sys_user. Reading the company or location directory alone does not prove that those fields are readable on a user. An HTTP success can still omit a protected field.

​

Domain visibility

In a domain-separated instance, the integration account needs visibility into the domains containing the referenced criteria and supporting records. A criterion can open for an administrator while the integration account receives a not-found response or an empty list. That does not prove the criterion was deleted. Ask your ServiceNow administrator to compare the record’s domain with the integration account’s domain and visibility grants. Compare record identifiers and domain paths because different domains can have the same name. Table read permission alone may not resolve domain filtering. If a visibility change is needed, review its scope across tables before applying it. ServiceNow recommends granting visibility through groups. Keep the article’s end-user criteria intact. Integration account visibility does not add support for per-user domain authorization on non-global articles. Keep the integration user in the Coordinated Universal Time (UTC) timezone. Table API cursor comparisons use the session timezone, and a non-UTC user can skip articles. Flow treats a date-only article expiry as the end of that date in UTC. An expiry with a time uses that exact timestamp. The initial listing uses the UTC day, and Flow checks expiry again before making content searchable.

​

Connect in Flow

Open Integrations, choose ServiceNow Knowledge Base, and complete the connection flow.

​

Article body mappings

Standard What is, How to, and Known error templates use built-in mappings. Custom template classes that keep the body on a subtype table need an explicit mapping. On the source, open Advanced. For each class, enter the ServiceNow Article class (sys_class_name) and the Field names in the order they should appear. Optional Heading values become section titles in the searchable body. Selected fields become searchable to the article’s authorized audience. Mapping a field does not grant anyone access. Mapping does not guarantee searchable text. Empty standard listing bodies do not need a mapping. Restore defaults replaces the list with the three standard templates. Deleting a default mapping stays deleted until you restore or add it again. Content retrieval names unmapped custom classes and incomplete mapped retrieval. Indexed listing text can still be searchable when mapped fields were missing or unreadable. Grant the dedicated integration role read access to each mapped table and field. Do not grant admin or knowledge_admin.

​

Scopes and permissions

The ServiceNow account needs the table reads in Prepare the provider. User Criteria also needs the criteria, people, group membership, and role information used by the selected criteria. Authorize only proves a bounded read of kb_knowledge. Run count counts that same table. The first sync also reads mapped template subtype tables, knowledge bases, User Criteria relationships, people, groups, roles, and attachments. Standard articles store their body in kb_knowledge.text. Mapped template classes store their sections on the matching subtype table. Flow follows sys_class_name and reads the configured fields. Grant the dedicated integration role read access to every mapped template table when the selected knowledge bases use those classes. ServiceNow can calculate a filter count before it removes rows from the Table API response. A count can therefore report more matching articles than the listing pages contain. Flow continues the crawl through the pages ServiceNow returns and shows a ServiceNow count mismatch warning. The warning compares the original filter count with the distinct articles returned across the whole crawl, including when a sync resumes mid-page. That warning is not a permissions error and not a failed sync. Grant the dedicated integration role scoped read access when articles you expect never appear in the listing. Do not grant admin or knowledge_admin. If expected content does not appear during setup, check ServiceNow access controls before widening the source scope.

​

Verify access

After the first sync:

• Confirm that expected articles and attachments are available in Flow.
• Test an article intended for a direct user, group, role, company, department, or location with an eligible person.
• Confirm that a person who is not included cannot find the restricted article.

​

Security notes

• Unsupported or unreadable criteria do not widen access.
• If a readable allow criterion names a user whose record Flow cannot read, Flow can still grant access to other readers it verifies. The unreadable user receives no access. Articles remain inaccessible when no verified reader satisfies the allow criteria. An unreadable user in a deny criterion still blocks access.
• You must select team and organization visibility explicitly. They do not activate because User Criteria cannot be used.
• Articles without criteria still follow the selected source access mode.

​

Sync and behavior

After the first sync, confirm that expected articles appear under Knowledge. Flow processes the articles ServiceNow returns in the listing pages. Search availability also requires usable content and a supported access decision. ServiceNow can report a filter count higher than the number of rows those pages contain. Open the source to see a ServiceNow count mismatch warning when that happens. The sync completed. The source stays connected, and the last successful sync time updates. For example, an HR knowledge source whose filter count says 1,875 can still finish after ServiceNow returns 1,793 distinct articles. Flow shows: “ServiceNow reported 1,875 matching articles but returned 1,793. Flow continued crawling available content.” Articles that never appear in those listing pages are not indexed. Flow does not delete existing articles because of the mismatch. If expected articles are missing, inspect the instance listing with the same integration user. Do not grant admin or knowledge_admin. Do not add the integration user to end-user Can Read criteria.

​

Permission refresh diagnostics

An incomplete permission refresh can retain the last known access decision. The source can therefore show a recent permission failure while an article remains readable under that retained decision. Some failures, including unreadable required membership fields or unavailable criteria, restrict access instead. After repairing permissions, refresh access and verify both an eligible reader and an excluded reader. Source diagnostics can link to affected ServiceNow articles, criteria, knowledge bases, or article classes. A sample link covers only the displayed sample, and links require your own ServiceNow access. Opening a link does not repair permissions. Article-class links include the source filters; Flow omits links that cannot include the complete selection within the URL limit.

​

Troubleshooting

​

Related topics

• ServiceNow ticketing
• Knowledge overview
• Troubleshoot connections and sync