> ## Documentation Index > Fetch the complete documentation index at: https://docs.letsflow.ai/llms.txt > Use this file to discover all available pages before exploring further. # ServiceNow Knowledge Base > Connect published ServiceNow KB articles to Flow knowledge search. ## 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 | Dimension | What Flow does | | - | - | | Direct users | Allows the named ServiceNow users who also exist in Flow. | | Groups | Checks group membership, including nested child groups, for people who already exist in Flow. | | User Criteria **Roles** | Checks whether people who already exist in Flow hold the role listed on a Can Read, Cannot Read, or Can Contribute User Criterion. Flow does not expand every ServiceNow account that has the role. | | Company, department, location | Checks those User Criteria fields against the matching fields on `sys_user` for people who already exist in Flow. | | Match all | When a criterion uses Match all, the person must satisfy every populated dimension on that criterion. | ### 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. | Restriction | What happens | | - | - | | Advanced or scripted User Criteria | A scripted allow criterion adds no verified readers. A separate supported allow criterion in the same list can grant access, subject to all other restrictions. A scripted deny criterion blocks access. | | Domain-separated articles outside the global domain | Flow does not infer per-user domain rules. The article stays out of search. | | Unreadable or incomplete criteria, groups, or roles | Flow can retain readers proven by a supported allow alternative or a valid returned membership. Unknown matches add no readers. Incomplete deny checks block access. | | A deny criterion that cannot be resolved for people in Flow | The whole article stays out of search. People who exist only in ServiceNow do not block the article. | 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](/integrations/ticketing/servicenow). 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: | Access | Tables | Why | | - | - | - | | Read | `kb_knowledge` | Article body, visibility, criteria references, and sync cursor fields | | Read | `kb_template_what_is`, `kb_template_how_to`, `kb_template_known_error_article` | Default body fields for What is, How to, and Known error templates | | Read | Mapped custom template tables | Body fields listed under **Advanced** for custom article classes | | Read | `kb_knowledge_base` | Knowledge-base identity and metadata | | Read | `kb_uc_can_read_mtom`, `kb_uc_cannot_read_mtom`, `kb_uc_can_contribute_mtom` | Knowledge-base User Criteria relationships inherited by articles | | Read | `user_criteria` | Criterion definitions, including users, groups, roles, company, department, location, and Match all | | Read | `sys_user` | Map ServiceNow people to Flow people, including company, department, and location | | Read | `sys_user_grmember`, `sys_user_group` | Expand group criteria, including nested child groups | | Read when article roles contain names | `sys_user_role` | Resolve exact role names to role IDs; requires `sys_id` and `name` | | Read | `sys_user_has_role` | Check whether people who already exist in Flow hold the role | | Read | Attachment API (`sys_attachment`) | Article attachment metadata and file bytes | 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](https://www.servicenow.com/docs/r/platform-security/t_GrVisDomIndUser.html). 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. | UI field | Required | Purpose | | - | - | - | | Team | Yes | Team that owns the ServiceNow binding | | ServiceNow instance URL | Yes | Tenant host | | Client ID | Yes | ServiceNow OAuth client ID | | Client secret | Yes | ServiceNow OAuth client secret | | Knowledge source scope | Per source | The whole instance, or the knowledge bases and articles to sync | | Access mode | Yes | `User Criteria`, `Available to Team`, or `Available to Org` | | Advanced article body mappings | No | Optional. Maps template fields into the searchable body | See [Prepare the provider](#prepare-the-provider). Use the instance URL and OAuth credentials. Select the whole instance, or open it to browse knowledge bases and their published articles and select the ones to sync. Each level loads one page at a time with **Load more**. Search matches article titles and numbers inside the open knowledge base, or across the instance at the top level. One source holds either the whole instance or up to 50 knowledge bases and articles. Changing the selection or the filter requires a new count before you can save. If custom templates store the body outside `kb_knowledge.text`, open **Advanced**, add the article class and ordered fields, and save. Standard What is, How to, and Known error templates do not need this step. After a mapping change, sync again. ## 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](#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 | Problem | What to check | | - | - | | Authorize fails immediately | Confirm Client ID and Client secret, that the OAuth client is active, and that the instance URL is the base host only. | | Authorize and **Run count** succeed, then the first sync fails | Authorize and **Run count** only read `kb_knowledge`. Check REST API Access Policies and **Allow access to this table via web services** on the crawl tables and the Attachment API. | | Filter count is higher than the synced count | Open the source and look for **ServiceNow count mismatch**. The sync completed for the articles ServiceNow returned. Those articles stay indexed. Missing articles were not in the listing pages and were not deleted. Inspect the same query with the integration user if you need those missing rows. Do not grant `admin` or `knowledge_admin`, and do not add the integration user to end-user **Can Read** criteria. | | A source connects but restricted articles are missing | Confirm the selected access mode and the integration user's access to `user_criteria`, `sys_user`, `sys_user_grmember`, `sys_user_group`, and `sys_user_has_role`. Empty success from ServiceNow can mean a permission miss. | | A criterion opens for an administrator but Flow reports it unavailable | Compare the criterion and integration account domains and visibility grants, then check record read rules. A not-found response can hide an existing record. See [Domain visibility](#domain-visibility). | | Company, department, or location criteria fail | Check the corresponding fields on both the criterion and the user record. A readable directory or successful HTTP response does not prove field access. | | Eligible people cannot find an article | Confirm the source uses User Criteria, the criterion uses a supported User Criteria dimension, the person is in Flow with a matching ServiceNow email, and the person holds at least one role when the article has a **Roles** restriction. | | A User Criteria role sync indexes articles that nobody can search | Confirm the integration user can read both the role and the user on `sys_user_has_role`. HTTP success plus a person row is not enough if the role column is missing. Grant those field reads on the dedicated integration role, then sync again. Do not grant `admin`. | | A large role sync never finishes or indexes nothing | Flow evaluates people who already exist in Flow, then checks whether those people hold the User Criteria role. Confirm `sys_user_has_role` and `sys_user` reads for the integration user, then sync again. | | Articles sync but nobody can search them | In User Criteria mode, check whether criteria are unsupported, unreadable, incomplete, or have no verified matching people in Flow. Article roles require a verified membership match. An unreadable role-membership column is incomplete. That is expected. Check the User Criteria, role membership, and table access, then sync again. | | Filter count looks right but attachments never appear | Grant Attachment API read. A REST API Access Policy can allow Table API GET and still block `/api/now/attachment`. | | An article syncs but shows no indexed content | Open **Content retrieval**. For a standard article, confirm the dedicated integration role can read `kb_knowledge.text`. For a mapped template class, grant read access to that subtype table and the configured fields. For an unmapped custom class with an empty listing body, add the class under **Advanced**, grant those table and field reads, then sync again. Mapping does not grant access and does not fill an empty standard body. Confirm web-service access and REST API Access Policies. Do not grant `admin` or `knowledge_admin`. | | Content retrieval lists an unmapped article class | The class is not in **Advanced** article body mappings, and the listing body was empty. Add the class and ordered fields if those fields hold the article body, grant the integration role read access, then sync again. | | Content retrieval says mapped fields were missing or unreadable | Indexed listing text can still be searchable. Confirm the mapping field names and that the integration role can read those subtype fields. Mapping a field does not grant access. | ## Related topics * [ServiceNow ticketing](/integrations/ticketing/servicenow) * [Knowledge overview](/integrations/knowledge/overview) * [Troubleshoot connections and sync](/setup/troubleshooting/connections-and-sync) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.