Communities practice questions

Dictionary overrides on the community table

Why it fails: Incorrect. Dictionary overrides control field-level attributes like default values or read-only states for specific tables.

Access Control Lists (ACLs) on the sys_user table

Why it fails: Incorrect. ACLs on sys_user control user profile access, not community forum visibility.

Client Scripts running on the portal login page

Why it fails: Incorrect. Client scripts run in the browser for form logic, not community access control.

User Administration > Badges

Why it fails: Incorrect. User badges for communities are managed inside community setup menus.

Customer Service > Administration > Reputation

Why it fails: Incorrect. Reputation management is centralized under the Community application, not general customer service administration.

Collaboration > Gamification > Badges

Why it fails: Incorrect. This is a fictitious navigation path.

kb_knowledge

Why it fails: Incorrect. kb_knowledge is strictly for knowledge base articles.

sn_customerservice_case

Why it fails: Incorrect. This is the case table, not the community content table.

sys_user

Why it fails: Incorrect. This table stores user records.

User Administration > Roles

Why it fails: Incorrect. User Administration > Roles is used for assigning base platform roles, not specific community forum parameters.

Knowledge Management > Administration

Why it fails: Incorrect. This module governs knowledge bases, not peer-to-peer community forums.

Service Portal > Portals > Community

Why it fails: Incorrect. Service Portal > Portals defines portal-level branding and pages, not forum categorization.

Service Portal > Widgets > Subscriptions

Why it fails: Incorrect. Widgets manage layout components, not user notification preferences.

System Notification > Email > Notifications

Why it fails: Incorrect. This is an administrator-level table, not accessible to regular portal users.

Active Directory synchronization settings

Why it fails: Incorrect. AD sync handles user authentication and import, not portal notification preferences.

Categories must be hardcoded via global business rules on every portal widget

Why it fails: Incorrect. Business rules on portal widgets are bad practice and categories are managed relationally.

Each portal must have an entirely distinct database instance for community data

Why it fails: Incorrect. ServiceNow uses a multi-tenant architecture on a single instance; separate instances are unnecessary.

Community threads cannot be viewed outside the specific portal where they were created

Why it fails: Incorrect. Community content can be surfaced across multiple portals configured with community widgets.

Delete all search sources and rely entirely on global text search

Why it fails: Incorrect. Global text search is legacy and deleting search sources breaks case deflection.

Add a client script to hide search results in the browser DOM

Why it fails: DOM manipulation is insecure because the underlying data is still transmitted to the client.

Disable Contextual Search globally during business hours

Why it fails: Incorrect. Disabling search defeats the purpose of case deflection.

Attaching a PDF export of the browser screen

Why it fails: Incorrect. PDF attachments are static files, not relational platform links.

Writing a client script on the sys_user table

Why it fails: Incorrect. This does not link records.

Changing the case category to 'Community'

Why it fails: Incorrect. Category is a classification field, not a linking mechanism.

Disabling the Service Portal header widget

Why it fails: Incorrect. Disabling headers breaks portal navigation entirely.

Global UI Actions on the Incident form

Why it fails: Incorrect. UI actions on incidents do not control community forum visibility.

Modifying the system-wide sn_customerservice_case dictionary

Why it fails: Incorrect. Dictionary settings control field attributes, not community forum access.

Requiring all global users to share a single unsegmented English-only forum

Why it fails: Incorrect. Forcing a single unsegmented forum creates a poor user experience for international customers.

Hardcoding all English forum text into client scripts

Why it fails: Incorrect. Hardcoding text prevents localization and violates development best practices.

sn_communities_admin

Why it fails: This is an administrative role meant for global community configuration and setup, not general end users.

sn_communities_content_author

Why it fails: This role typically pertains to authoring specific rich content or articles rather than provisioning new forums.

sn_communities_moderator

Why it fails: This role is used for moderation tasks such as approving content and managing flags, not standard forum creation.

In the User Criteria definition assigned to the Forums table

Why it fails: User Criteria determines who can access forums, not what content is filtered, so profanity would still post. It tempts because it governs forum behaviour, and would be correct when restricting forum visibility to users meeting set conditions.

In the Forum Access Controls (ACLs) for the sn_communities_content table

Why it fails: Community content filtering is configured through Community Profile settings, which apply moderation rules to posts before publication; sn_communities_content ACLs only govern record-level read, write and delete permissions on that table. ACLs are tempting because they restrict who can access forum records, which suits locking down visibility rather than scanning text for profanity.

In the Case Deflection Settings module under Community Configuration

Why it fails: Case Deflection Settings control suggested knowledge articles during case creation, with no profanity-filtering capability for forum posts. It tempts because it sits under Community Configuration, and would be correct when tuning deflection offers shown to users submitting cases.

The Forum Access Control List (ACL) definitions for the sn_communities_forum table

Why it fails: While ACLs apply, private forums specifically rely on User Criteria associations managed out-of-the-box.

The CSM Community Property table for the property glide.community.private.disable

Why it fails: This property does not exist in standard ServiceNow community configurations.

The Portal Page widget security settings in Service Portal Configuration

Why it fails: Portal widget security controls page-level access, whereas forum content security is record-level and criteria-driven.

Run an on-demand background script to copy the discussion text into the Incident table

Why it fails: Background scripts are administrative tools, not standard features for daily moderator workflows.

Change the state field of the community post directly to 'Converted to Case'

Why it fails: Changing the state alone does not trigger case creation unless tied to a custom business logic workflow.

Export the discussion thread to XML and import it into the Case [sn_customerservice_case] table

Why it fails: XML export/import is an administrative migration tool, not a functional moderation action.

Service Portal > Pages > Community Portal

Why it fails: Service Portal modules manage layouts and widgets, not the hierarchical taxonomy of community forums.

Customer Service > Administration > Properties

Why it fails: General system properties do not define the hierarchical relationship of community forums.

AI Search > Result Sources > Community

Why it fails: AI Search result sources configure indexing parameters, not forum structures.

Knowledge > Articles > Flagged

Why it fails: This module handles flagged knowledge articles, not peer-to-peer community forum posts.

Community Administration > Flagged Content

Why it fails: The exact navigation path uses the Community Moderation module.

Customer Service > Cases > Open

Why it fails: Flagged community posts do not route to the standard Customer Service case queue by default.

Forum subscription settings

Why it fails: Forum subscription settings determine which notifications a user receives about new posts or replies, not who can view the content. Subscriptions are user-controlled and do not restrict access; they merely alert users to activity. Therefore, they cannot enforce visibility restrictions based on product ownership or customer verification.

Access control lists (ACLs) on the forum table

Why it fails: While ACLs can restrict access at the table level, they are not designed for granular, attribute-based visibility within community forums. ACLs typically control record-level operations and would require complex scripting, whereas community user criteria are purpose-built for community segmentation and are easier to manage for this scenario. ACLs would not efficiently enforce product ownership conditions without custom development.

Community permissions by role

Why it fails: Community permissions by role grant broad capabilities such as posting, commenting, or moderating based on user roles, but they do not filter content visibility based on dynamic attributes like product ownership. This feature controls what actions a user can perform, not which specific threads they can see, so it cannot enforce the required restriction.

The community forum is configured with the 'CSM Integration' property set to true, which enables automatic case creation from questions.

Why it fails: There is no 'CSM Integration' property on community forums that automatically creates cases from questions. While CSM and Communities can be integrated, the creation of cases from community questions is typically a manual or scripted process, not a simple property toggle. This option describes a non-existent feature and would not achieve the desired automatic visibility and linkage.

The customer service case is published to the community as a knowledge article, and the community question is linked through the knowledge base.

Why it fails: Publishing a case as a knowledge article and linking through the knowledge base does not create a community question. Knowledge articles and community questions are distinct content types. While knowledge can be surfaced in communities, this method would not automatically generate a question thread or maintain a direct case-to-question association. It also requires manual conversion and does not provide the automatic linkage expected.

The community plugin is active and the forum is linked to the CSM case table via a many-to-many relationship.

Why it fails: Activating the community plugin and creating a many-to-many relationship between forums and the case table does not automatically create or link community questions to cases. The integration relies on specific business rules and UI actions within the CSM application, not just table relationships. This approach would require extensive custom development and would not provide the out-of-box behavior expected for case-to-community linkage.

Enable the 'Auto-provision users' property in the community portal settings.

Why it fails: There is no such property as 'Auto-provision users' in community portal settings. User provisioning is controlled through SSO configuration and identity provider settings, not a generic portal property. This option is a distractor based on a misunderstanding of where provisioning is configured in ServiceNow.

Create a dedicated local user account for each external customer and map it to the SAML assertion.

Why it fails: Manually creating local accounts for each external customer defeats the purpose of automatic provisioning and is not scalable. While it could work technically, it does not meet the requirement for automatic provisioning upon first login and introduces significant administrative overhead. The scenario explicitly asks for automatic provisioning, so this approach is incorrect.

Assign the snc_community_user role to the SAML assertion in the IdP.

Why it fails: While roles can be mapped from SAML assertions, assigning the snc_community_user role alone does not provision a user account. The user must first exist in the system, and role assignment typically occurs after provisioning. This option confuses role mapping with user creation, and does not address the automatic creation of user records required for first-time login.

Enable the 'Allow Anonymous Access' property in the forum record and set the 'Anonymous User' field to 'guest'.

Why it fails: There is no 'Allow Anonymous Access' property on a forum record, nor an 'Anonymous User' field. Anonymous access in Communities is not controlled via a simple property on the forum. Instead, it relies on user criteria that evaluate to true for unauthenticated users. This option describes a non-existent feature and would not achieve the desired result.

Set the forum's 'Access Control' to 'Public' and grant the 'sn_communities.public' role to all users.

Why it fails: Setting access control to 'Public' and granting a role to all users is not the correct method. The 'sn_communities.public' role does not exist, and access control for forums is managed through user criteria, not a simple role assignment. This approach would not work and could create security gaps if misconfigured.

Add the 'public' role to the forum's ACLs and set the 'Requires Authentication' flag to false.

Why it fails: Access to forums is not managed through ACLs directly on the forum record, and there is no 'Requires Authentication' flag. The correct mechanism is user criteria, which determine read and contribute permissions. Using ACLs would be a low-level approach that bypasses the intended configuration model and could lead to inconsistent behavior. This option is incorrect.