Troubleshooting practice questions

An administrator is troubleshooting why an SLA timer is incorrectly continuing to run while a CSM Case is in a paused state. Which THREE common configuration issues should the administrator investigate? (Choose three.)

Trap 1: The system property com.glide.sla.pause_enabled is set to false.

No such global property exists to globally disable pauses in this manner.

Trap 2: The Task SLA table has read-only ACLs preventing the state update.

ACLs block user UI updates, not backend SLA engine state transitions.

A
The Case state value being used in practice does not match the backend choice value specified in the pause condition.
Mismatched display labels vs. backend choice values (e.g., 'Awaiting Info' vs 'awaiting_info') will prevent condition evaluation.
B
The Pause condition field on the SLA Definition is empty or incorrectly formulated.
If the pause condition is blank or references invalid fields, the engine will never trigger a pause.
C
The system property com.glide.sla.pause_enabled is set to false.
Why it fails: No such global property exists to globally disable pauses in this manner.
D
Another matching SLA definition with a higher order (lower number) lacks a pause condition, overriding the behavior.
Precedence rules can cause a different matching SLA definition to dictate the runtime behavior.
E
The Task SLA table has read-only ACLs preventing the state update.
Why it fails: ACLs block user UI updates, not backend SLA engine state transitions.

Question 2mediummultiple choice

What is the primary function of the 'Case Audit' history?

Trap 1: To allow agents to edit past notes

Case Audit records a chronological trail of case field changes and actions for compliance review; it is read-only and cannot modify notes. Editing past notes is performed through the case's own edit function, subject to permissions, so the audit history is the wrong mechanism for that task.

Trap 2: To record email delivery status

Case Audit history logs field-level changes to a case, such as status, owner and priority edits, not outbound email delivery outcomes. Email tracking belongs to notification or activity records. Case Audit is the right choice when reconstructing who changed which case field and when.

Trap 3: To track SLA time

Case Audit history captures modifications to case fields and records, not elapsed time against entitlement targets. SLA timers are tracked through entitlement and milestone fields. Case Audit is correct when the requirement is reconstructing field-level change history for compliance or troubleshooting.

A
To allow agents to edit past notes
Why it fails: Case Audit records a chronological trail of case field changes and actions for compliance review; it is read-only and cannot modify notes. Editing past notes is performed through the case's own edit function, subject to permissions, so the audit history is the wrong mechanism for that task.
B
To provide a read-only log of changes made to the case record
Case Audit history records every field change made to a case, satisfying the requirement for a read-only, tamper-evident log. It captures who changed what and when, supporting compliance and troubleshooting without permitting edits to the recorded entries.
C
To record email delivery status
Why it fails: Case Audit history logs field-level changes to a case, such as status, owner and priority edits, not outbound email delivery outcomes. Email tracking belongs to notification or activity records. Case Audit is the right choice when reconstructing who changed which case field and when.
D
To track SLA time
Why it fails: Case Audit history captures modifications to case fields and records, not elapsed time against entitlement targets. SLA timers are tracked through entitlement and milestone fields. Case Audit is correct when the requirement is reconstructing field-level change history for compliance or troubleshooting.

Question 3hardmultiple choice

An implementation specialist is troubleshooting why an SLA is not attaching to a newly created CSM case. Upon checking the SLA Definition, the specialist notices the 'Target' field is set to 'Resolution'. What is the primary function of the Target field in an SLA Definition?

Trap 1: It determines which user group receives breach notifications.

The Target field specifies whether the SLA measures the Resolution or Response timeline; breach notification recipients are configured separately in the SLA's workflow or notification settings. Notification routing is tempting because breaches must be escalated somewhere, but the Target field never determines recipient groups.

Trap 2: It restricts the SLA to a specific customer tier.

The Target field selects which SLA timeline the definition measures against — Resolution or Response — not a customer tier. Tier restriction is tempting because SLAs are often segmented by customer, but that segmentation is achieved through start conditions and filters, not the Target field.

Trap 3: It defines the specific workflow that executes when the SLA…

The Target field selects the metric the SLA measures — for example Resolution or Response — not a breach workflow. Breach actions are configured separately through SLA workflows or business rules. It is tempting because Target sounds like an outcome trigger, and workflow configuration is a genuine SLA Definition component, but it never defines which workflow executes.

A
It determines which user group receives breach notifications.
Why it fails: The Target field specifies whether the SLA measures the Resolution or Response timeline; breach notification recipients are configured separately in the SLA's workflow or notification settings. Notification routing is tempting because breaches must be escalated somewhere, but the Target field never determines recipient groups.
B
It restricts the SLA to a specific customer tier.
Why it fails: The Target field selects which SLA timeline the definition measures against — Resolution or Response — not a customer tier. Tier restriction is tempting because SLAs are often segmented by customer, but that segmentation is achieved through start conditions and filters, not the Target field.
C
It specifies the type of SLA timer (e.g., Resolution, Response) and sets the metric objective type.
The Target field determines which SLA timer the definition governs, such as Resolution or Response, and sets the metric objective type the engine evaluates. Setting it to Resolution means the definition only attaches to resolution-based timers.
D
It defines the specific workflow that executes when the SLA breaches.
Why it fails: The Target field selects the metric the SLA measures — for example Resolution or Response — not a breach workflow. Breach actions are configured separately through SLA workflows or business rules. It is tempting because Target sounds like an outcome trigger, and workflow configuration is a genuine SLA Definition component, but it never defines which workflow executes.

Question 4easymultiple choice

An agent is viewing a case and wants to create a new knowledge article capturing the troubleshooting steps taken. Which UI action facilitates this directly from the case form?

Trap 1: Convert to Article

Convert to Article creates a draft from case fields and resolution notes, but it does not let the agent capture free-text troubleshooting steps interactively; that is what the Knowledge Article action on the case form does. Convert to Article suits promoting an existing resolved case into a published article.

Trap 2: Publish to Knowledge Base

Publishing pushes an article live to the knowledge base, which is a separate lifecycle step from drafting one from case data. It is tempting because publishing is the correct action once an article is authored and approved, but the agent first needs the creation action that pre-populates a draft from the case.

Trap 3: Send Knowledge Article

Sending a knowledge article delivers an existing article to a recipient; it does not create a new draft from the case's troubleshooting steps. It is tempting because sending is the correct action when an agent wants to share already-published content with a customer, not when capturing new resolution detail.

A
Create Knowledge
The Create Knowledge UI action on the case form launches article creation with case fields pre-populated, letting the agent capture troubleshooting steps without leaving the record. This directly satisfies the requirement to author an article from the case itself.
B
Convert to Article
Why it fails: Convert to Article creates a draft from case fields and resolution notes, but it does not let the agent capture free-text troubleshooting steps interactively; that is what the Knowledge Article action on the case form does. Convert to Article suits promoting an existing resolved case into a published article.
C
Publish to Knowledge Base
Why it fails: Publishing pushes an article live to the knowledge base, which is a separate lifecycle step from drafting one from case data. It is tempting because publishing is the correct action once an article is authored and approved, but the agent first needs the creation action that pre-populates a draft from the case.
D
Send Knowledge Article
Why it fails: Sending a knowledge article delivers an existing article to a recipient; it does not create a new draft from the case's troubleshooting steps. It is tempting because sending is the correct action when an agent wants to share already-published content with a customer, not when capturing new resolution detail.

Question 5mediummultiple choice

A company has enabled external community integration with CSM. Customers frequently post troubleshooting questions on the community. When a community question is successfully resolved by a peer or agent, what mechanism can be used to convert that community thread into an official knowledge base article?

Trap 1: Run a background script to export community posts to XML

A background script exporting posts to XML produces a static file with no knowledge record, no article template, and no publication workflow. It tempts for bulk extraction or migration reporting, but converting a resolved thread requires the built-in community-to-knowledge article creation mechanism, not scripted export.

Trap 2: Set up a scheduled Data Import job for community tables

Scheduled imports pull community table records into ServiceNow on a timer; they cannot promote a resolved thread into a published knowledge article with mapped fields and workflow. It tempts for bulk data ingestion, but conversion requires the community-to-knowledge mechanism that creates an article from the thread.

Trap 3: Configure an Inbound Email Action on the knowledge base table

Inbound Email Actions fire on received email, not on community thread state changes, so a resolved question never triggers article creation. It tempts because email actions do generate records from inbound messages, but community-to-knowledge conversion needs the dedicated community knowledge integration, not mail processing.

A
Run a background script to export community posts to XML
Why it fails: A background script exporting posts to XML produces a static file with no knowledge record, no article template, and no publication workflow. It tempts for bulk extraction or migration reporting, but converting a resolved thread requires the built-in community-to-knowledge article creation mechanism, not scripted export.
B
Set up a scheduled Data Import job for community tables
Why it fails: Scheduled imports pull community table records into ServiceNow on a timer; they cannot promote a resolved thread into a published knowledge article with mapped fields and workflow. It tempts for bulk data ingestion, but conversion requires the community-to-knowledge mechanism that creates an article from the thread.
C
Use the 'Create Knowledge' UI action on the community question record
The 'Create Knowledge' UI action on the community question record copies the thread's question and accepted answer into a new knowledge article draft. This satisfies the requirement to convert a resolved community thread into an official knowledge base article.
D
Configure an Inbound Email Action on the knowledge base table
Why it fails: Inbound Email Actions fire on received email, not on community thread state changes, so a resolved question never triggers article creation. It tempts because email actions do generate records from inbound messages, but community-to-knowledge conversion needs the dedicated community knowledge integration, not mail processing.

Question 6hardmulti select

When troubleshooting why community posts are flagged by moderation rules, which THREE areas should an administrator investigate? (Choose three.)

Trap 1: Mid Server certificate expiration dates

Mid Server certificates affect Discovery and Service Graph Connector communication, not community moderation. It tempts because certificate expiry genuinely breaks integrations and produces errors, but moderation flagging depends on rule conditions, keyword lists, user reputation and content state, not MID infrastructure.

Trap 2: The system mail boxes for outbound SMTP server status

Outbound SMTP mailbox status governs notification delivery, not whether a post is flagged. It tempts because mail failures are a common ServiceNow troubleshooting target and moderation can trigger notifications, but flagging is decided by moderation rules, keywords, user reputation and content type settings.

A
Mid Server certificate expiration dates
Why it fails: Mid Server certificates affect Discovery and Service Graph Connector communication, not community moderation. It tempts because certificate expiry genuinely breaks integrations and produces errors, but moderation flagging depends on rule conditions, keyword lists, user reputation and content state, not MID infrastructure.
B
User trust levels or author reputation thresholds that might bypass moderation
Trust levels and reputation thresholds directly govern whether a post enters the moderation queue or publishes automatically. A high-trust author can bypass keyword or spam filters entirely, so a flagged post may reflect a misconfigured threshold rather than a rule fault. Investigating this area satisfies the stem's requirement to trace why moderation rules flag community posts.
C
Moderation audit logs or status fields on the flagged content record
Moderation audit logs and status fields record which rule fired, the matched keyword or threshold, and the resulting state, so they pinpoint the exact trigger behind each flag. This satisfies the stem's requirement to investigate why posts are flagged, exposing rule configuration or content mismatches rather than mere symptom counts.
D
The system mail boxes for outbound SMTP server status
Why it fails: Outbound SMTP mailbox status governs notification delivery, not whether a post is flagged. It tempts because mail failures are a common ServiceNow troubleshooting target and moderation can trigger notifications, but flagging is decided by moderation rules, keywords, user reputation and content type settings.
E
Configured moderation rules and keyword filter lists
Moderation rules and keyword filter lists define exactly which terms or patterns trigger flagging, so inspecting them reveals whether an overly broad keyword or misconfigured rule is catching legitimate community posts. This directly satisfies the stem's requirement to investigate the configured moderation logic causing the flags.

Question 7mediummulti select

Which TWO of the following can be used to track case performance?

Trap 1: Table dictionary

A table dictionary stores schema metadata — field names, types and relationships — and holds no case activity data. It is tempting because it documents the case table's structure, and would be correct when you need to identify which columns exist before building a report or query.

Trap 2: System logs

System logs record platform and application events, not case metrics such as resolution time or status progression. They are tempting because they are the first place engineers look when diagnosing behaviour, and would be correct for auditing access, tracing errors or troubleshooting a failing component.

Trap 3: Email client

An email client sends and receives messages; it holds no aggregated case records or performance metrics. It is tempting because case notifications often arrive by email, and would be correct for corresponding with customers or receiving alerts, not for measuring case throughput or resolution.

A
Standard Reports
Standard Reports query case objects natively, letting you aggregate metrics such as open volume, age, and resolution time by owner or status. They satisfy the tracking requirement without custom development, unlike dashboards alone or list views, which show records rather than performance trends.
B
Table dictionary
Why it fails: A table dictionary stores schema metadata — field names, types and relationships — and holds no case activity data. It is tempting because it documents the case table's structure, and would be correct when you need to identify which columns exist before building a report or query.
C
System logs
Why it fails: System logs record platform and application events, not case metrics such as resolution time or status progression. They are tempting because they are the first place engineers look when diagnosing behaviour, and would be correct for auditing access, tracing errors or troubleshooting a failing component.
D
Performance Analytics Dashboards
Performance Analytics Dashboards aggregate case metrics such as resolution time, backlog and SLA attainment into visualised trends, enabling managers to track case performance over time. They satisfy the requirement for ongoing measurement rather than static reporting.
E
Email client
Why it fails: An email client sends and receives messages; it holds no aggregated case records or performance metrics. It is tempting because case notifications often arrive by email, and would be correct for corresponding with customers or receiving alerts, not for measuring case throughput or resolution.

Question 8hardmultiple choice

A CSM administrator is troubleshooting why a newly published knowledge article is not appearing in portal searches. The article is published, and the user has read access to the knowledge base. What is another common configuration cause to check?

Trap 1: Verify that the user's browser cache has been cleared on the…

Browser cache is client-side and cannot prevent an article from being indexed or returned by portal search for other users; it only affects what one browser displays. Clearing cache is tempting because stale content often explains display issues, but it is not a server-side search configuration cause.

Trap 2: The article's workflow state must be manually synced with AI Search…

Indexing is automatic on publish; no manual sync of workflow state to AI Search indexer tables exists as an administrator task. Manual sync is tempting because indexer lag feels plausible, but the real check is article visibility and knowledge base search configuration.

Trap 3: Ensure the article has at least 5 positive ratings before indexing

Ratings are user feedback metadata and play no part in indexing or search eligibility; an article becomes searchable once published and permissioned. Rating thresholds are tempting because popularity can influence ranking, but ranking is not the same as appearing in results at all.

A
Verify that the user's browser cache has been cleared on the instance node
Why it fails: Browser cache is client-side and cannot prevent an article from being indexed or returned by portal search for other users; it only affects what one browser displays. Clearing cache is tempting because stale content often explains display issues, but it is not a server-side search configuration cause.
B
Check AI Search or Contextual Search Source configurations and search profile index status
Even when published and readable, an article may be absent from search if the search source or profile index has not indexed it. Verifying AI Search or Contextual Search Source configuration and index status addresses this indexing constraint.
C
The article's workflow state must be manually synced with AI Search indexer tables
Why it fails: Indexing is automatic on publish; no manual sync of workflow state to AI Search indexer tables exists as an administrator task. Manual sync is tempting because indexer lag feels plausible, but the real check is article visibility and knowledge base search configuration.
D
Ensure the article has at least 5 positive ratings before indexing
Why it fails: Ratings are user feedback metadata and play no part in indexing or search eligibility; an article becomes searchable once published and permissioned. Rating thresholds are tempting because popularity can influence ranking, but ranking is not the same as appearing in results at all.

Question 9hardmulti select

An implementation specialist is troubleshooting an issue where SLAs are attaching multiple times to the same CSM case. Which THREE configuration errors typically cause duplicate SLA attachment? (Choose three.)

Trap 1: The Task SLA table has duplicate dictionary overrides.

Duplicate dictionary overrides on Task SLA alter field behaviour or trigger conditions; they do not create multiple SLA records against one case. Overrides are used to customise SLA field values per table. Duplicate attachment stems from overlapping start conditions or missing stop conditions instead.

Trap 2: The com.glide.sla.duplicate_prevention property is set to true.

Setting duplicate_prevention to true suppresses duplicate SLA attachments, so it cannot cause them; it is the remediation. The property exists precisely to stop a task matching an SLA it already has. Duplicate attachment arises from misconfigured start conditions or absent stop conditions.

A
Business rules on the Case table manually trigger SLA creation while the background engine is also running.
A custom business rule that inserts Task SLA records directly duplicates the work of the SLA background engine, which already evaluates SLA Definitions and attaches SLAs. Both paths create separate Task SLA records for the same case, producing duplicate attachments.
B
A reset condition is incorrectly configured, causing the SLA to constantly cancel and restart in an infinite loop.
A misconfigured reset condition cancels the running SLA task and restarts it, so the same case repeatedly re-enters the SLA workflow. Each restart attaches a fresh SLA record, producing the duplicate attachments described in the troubleshooting scenario.
C
The Task SLA table has duplicate dictionary overrides.
Why it fails: Duplicate dictionary overrides on Task SLA alter field behaviour or trigger conditions; they do not create multiple SLA records against one case. Overrides are used to customise SLA field values per table. Duplicate attachment stems from overlapping start conditions or missing stop conditions instead.
D
Multiple active SLA Definitions have identical or overlapping start conditions and distinct orders that allow both to evaluate as true.
When several active SLA definitions share identical or overlapping start conditions, each evaluates true for the same case and attaches its own SLA. Distinct order values do not prevent this unless one definition's condition excludes the others, so duplicates result.
E
The com.glide.sla.duplicate_prevention property is set to true.
Why it fails: Setting duplicate_prevention to true suppresses duplicate SLA attachments, so it cannot cause them; it is the remediation. The property exists precisely to stop a task matching an SLA it already has. Duplicate attachment arises from misconfigured start conditions or absent stop conditions.

Question 10mediummulti select

Which TWO of the following are primary channels for creating a CSM case?

Trap 1: Knowledge base

The knowledge base is a self-service repository of articles for researching known issues, not a submission channel that opens a case. It is tempting because it is a support portal feature, but it would be the right choice only for finding an existing resolution before contacting support.

Trap 2: Dashboards

Dashboards display aggregated metrics and status views for monitoring; they present information rather than submitting support requests. They are tempting because they sit within the same portal as case creation, but they would be the right choice for tracking health or trends, not for opening a CSM case.

Trap 3: System logs

System logs are diagnostic output generated by products and collected for troubleshooting; they are consumed by support engineers, not used by customers to raise cases. They are tempting because they accompany case evidence, but they would be relevant when attaching diagnostics to an existing case.

A
Service Portal
The Service Portal provides the primary self-service channel for CSM case creation, letting customers submit requests directly through configurable catalogue items and record producers. This satisfies the stem's requirement for a primary channel, as portal submissions generate cases automatically without agent intervention, unlike secondary methods such as email or phone.
B
Knowledge base
Why it fails: The knowledge base is a self-service repository of articles for researching known issues, not a submission channel that opens a case. It is tempting because it is a support portal feature, but it would be the right choice only for finding an existing resolution before contacting support.
C
Dashboards
Why it fails: Dashboards display aggregated metrics and status views for monitoring; they present information rather than submitting support requests. They are tempting because they sit within the same portal as case creation, but they would be the right choice for tracking health or trends, not for opening a CSM case.
D
System logs
Why it fails: System logs are diagnostic output generated by products and collected for troubleshooting; they are consumed by support engineers, not used by customers to raise cases. They are tempting because they accompany case evidence, but they would be relevant when attaching diagnostics to an existing case.
E
Email
Email is a primary channel for creating a CSM case, satisfying the requirement for supported intake methods. Messages sent to the designated support address are automatically converted into cases within the ServiceNow CSM application, ensuring requests are captured without manual entry. This direct integration makes email one of the two correct channels.

Question 11hardmulti select

An implementation specialist is troubleshooting article versioning behavior in a CSM environment. Which THREE statements regarding knowledge article versioning are correct? (Choose three.)

Trap 1: Article versioning requires the activation of Domain Separation…

Domain Separation governs multi-tenant data partitioning, not versioning; versioning is enabled per knowledge base configuration. It is tempting because domain separation does affect article visibility across domains, so administrators working in partitioned instances may assume it also controls version records, but the two features are independent.

Trap 2: Checking out a published article automatically unpublishes the live…

Checkout flags the article as being edited but leaves the published version live and viewable until the draft is published again. Immediate unpublishing occurs only when an author explicitly unpublishes the article, not as a side effect of checking it out.

A
Administrators can view previous versions of an article from the Versions related list.
Administrators access prior article iterations through the Versions related list, which records each saved revision as a separate entry. This satisfies the scenario's requirement to inspect historical article states without restoring them, since the related list exposes version metadata and content snapshots directly on the article record.
B
Article versioning requires the activation of Domain Separation plugin.
Why it fails: Domain Separation governs multi-tenant data partitioning, not versioning; versioning is enabled per knowledge base configuration. It is tempting because domain separation does affect article visibility across domains, so administrators working in partitioned instances may assume it also controls version records, but the two features are independent.
C
Publishing a checked-out draft version automatically archives the previous published version as an older version.
Publishing a checked-out draft replaces the current published version and automatically archives that previous published version as an older version. This preserves the prior content in version history while the new draft becomes the live article.
D
When an author checks out a published article, a new draft version is created while the published version remains viewable to readers.
Checking out a published article creates a separate draft version, leaving the published version live and readable. This satisfies the scenario's versioning constraint: authors edit without unpublishing, so readers keep accessing the current published article while the draft evolves independently until republished.
E
Checking out a published article automatically unpublishes the live version immediately.
Why it fails: Checkout flags the article as being edited but leaves the published version live and viewable until the draft is published again. Immediate unpublishing occurs only when an author explicitly unpublishes the article, not as a side effect of checking it out.

Question 12easymultiple choice

A CSM administrator is troubleshooting why a newly created SLA Definition is not attaching to cases. The definition has a valid Start condition, a correct schedule, and a target of eight hours. Cases are being created and updated normally. Which field should the administrator check first to confirm the definition applies to the Case table?

Trap 1: The 'Workflow' field on the SLA Definition, which links the…

The workflow reference controls post-attachment behavior such as notifications and escalations, not whether the SLA attaches in the first place. A definition with no workflow can still attach and track time. This field is relevant after attachment, not for diagnosing why no SLA record appears.

Trap 2: The 'Collection' field on the SLA Definition, which groups related…

A collection groups SLA Definitions for organizational or reporting purposes and does not control which table the engine evaluates. A definition in any collection still attaches based on its Table field and conditions. Checking the collection would not explain why the SLA is not attaching to cases.

Trap 3: The 'Type' field on the SLA Definition, which classifies the SLA as…

The Type field distinguishes SLA categories such as SLA, OLA, and underpinning contract, affecting reporting and relationships. It does not determine the target table. A definition of any type attaches based on its Table field and conditions, so this field would not explain the missing attachment.

A
The 'Workflow' field on the SLA Definition, which links the definition to a workflow for notifications.
Why it fails: The workflow reference controls post-attachment behavior such as notifications and escalations, not whether the SLA attaches in the first place. A definition with no workflow can still attach and track time. This field is relevant after attachment, not for diagnosing why no SLA record appears.
B
The 'Collection' field on the SLA Definition, which groups related definitions for reporting.
Why it fails: A collection groups SLA Definitions for organizational or reporting purposes and does not control which table the engine evaluates. A definition in any collection still attaches based on its Table field and conditions. Checking the collection would not explain why the SLA is not attaching to cases.
C
The 'Table' field on the SLA Definition, which specifies the task table the definition targets, such as the Case table.
The Table field on an SLA Definition determines which task table the engine evaluates. If it is set to a table other than the Case table, the definition never attaches to cases regardless of how correct the conditions and schedule are. Verifying this field is the first logical troubleshooting step when an SLA does not attach.
D
The 'Type' field on the SLA Definition, which classifies the SLA as operational or underpinning.
Why it fails: The Type field distinguishes SLA categories such as SLA, OLA, and underpinning contract, affecting reporting and relationships. It does not determine the target table. A definition of any type attaches based on its Table field and conditions, so this field would not explain the missing attachment.

Question 13mediummultiple choice

A community manager at a medical device company needs to ensure that only users with an active support entitlement can view and post in a private forum dedicated to troubleshooting a regulated product. The forum must be hidden from users without that entitlement, and the restriction must apply consistently across forum lists, search results, and direct URLs. Which ServiceNow configuration should the manager use to meet this requirement?

Trap 1: Configure an ACL on the forum table that requires the user to have…

Table-level ACLs control record access at the database layer, but community forum visibility and posting permissions are primarily governed by user criteria, not by direct ACLs on the forum table. Requiring a broad role such as sn_customerservice.customer would not enforce the specific support entitlement condition and could expose the forum to users who should not see it.

Trap 2: Create a community group for entitled users and assign the forum to…

Community groups can organize users, but forum-level access in ServiceNow Communities is not controlled by group membership alone. Without linking user criteria to the forum's Can Read and Can Contribute lists, group membership does not enforce the entitlement requirement across all access paths, including search and direct URLs.

Trap 3: Set the forum's Access Type to 'Private' and manually invite each…

While a private forum restricts visibility, manually inviting each user is not scalable and does not automatically enforce an entitlement condition. It also risks human error and does not dynamically adapt when entitlements change. The requirement calls for an automated, condition-based restriction, which manual invitations cannot reliably provide.

A
Configure an ACL on the forum table that requires the user to have the sn_customerservice.customer role.
Why it fails: Table-level ACLs control record access at the database layer, but community forum visibility and posting permissions are primarily governed by user criteria, not by direct ACLs on the forum table. Requiring a broad role such as sn_customerservice.customer would not enforce the specific support entitlement condition and could expose the forum to users who should not see it.
B
Create a community group for entitled users and assign the forum to that group, relying on group membership for access.
Why it fails: Community groups can organize users, but forum-level access in ServiceNow Communities is not controlled by group membership alone. Without linking user criteria to the forum's Can Read and Can Contribute lists, group membership does not enforce the entitlement requirement across all access paths, including search and direct URLs.
C
Set the forum's Access Type to 'Private' and manually invite each entitled user to the forum.
Why it fails: While a private forum restricts visibility, manually inviting each user is not scalable and does not automatically enforce an entitlement condition. It also risks human error and does not dynamically adapt when entitlements change. The requirement calls for an automated, condition-based restriction, which manual invitations cannot reliably provide.
D
Create a user criteria record that checks for the support entitlement and associate it with the forum through the forum's Can Read and Can Contribute related lists.
Forum access in ServiceNow Communities is governed by user criteria records linked to the forum via the Can Read and Can Contribute related lists. A user criteria record can evaluate conditions such as an active support entitlement, and the platform enforces it consistently across lists, search, and direct navigation. This is the native, supported mechanism for entitlement-based forum visibility.