> ## 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 access control

> How Flow decides who can read synced ServiceNow KB articles.

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

You choose who can read each source under **Read access**:

1. **ServiceNow permissions**
   * The default. Flow uses supported ServiceNow criteria to identify who can search an article.
2. **ServiceNow permissions + selected teams**
   * Flow uses supported ServiceNow criteria. Current members of the selected teams can also read the indexed copy, even when ServiceNow would deny them. Criteria, article roles, and the **Allow everyone when no restrictions apply** setting never restrict those team members.
3. **Only selected teams**
   * Current members of the selected teams can read the indexed copy, even when ServiceNow would deny them.
4. **Everyone in the organization**
   * Every current member of the organization can read the indexed copy. Only an organization admin can choose this.

Flow does not switch to a team or organization option on its own when it cannot use User Criteria. You must choose one.

## 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.

When **Read access** uses ServiceNow permissions, Flow supports the **Roles** field on an article. 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, open the source and select **Sync**. A sync includes an **Access check**, which refreshes who can read each article. When **Sync activity** shows the sync and its **Access check** finished, test both an eligible reader and an excluded reader.

When **Read access** uses ServiceNow permissions, Flow always enforces populated article roles. 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. **Only selected teams** and **Everyone in the organization** 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

When **Read access** uses ServiceNow permissions, 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 and no article roles are readable by every member of your organization when **Allow everyone when no restrictions apply** is on. This setting appears under **Read access** when you add the source and on the source's **Read access** tab. It appears only when **Read access** is **ServiceNow permissions** or **ServiceNow permissions + selected teams**. A new source has it on. Only an organization admin can turn it on. Turning it off does not need an organization admin. When it is off, people who rely on ServiceNow permissions cannot read those articles. The setting does not apply to articles that have roles. Flow always checks those roles, and only verified role holders who rely on ServiceNow permissions can read the article. With **ServiceNow permissions + selected teams**, members of the selected teams can read these articles either way. With **Only selected teams** and **Everyone in the organization**, Flow skips User Criteria and uses the selected audience.

## Related topics

* [ServiceNow Knowledge Base](https://docs.letsflow.ai/integrations/knowledge/servicenow-kb.md)
* [Knowledge overview](https://docs.letsflow.ai/integrations/knowledge/overview.md)