Scenario practice questions

Which TWO statements are true regarding how the SLA engine handles Case re-opening scenarios? (Choose two.)

Trap 1: Re-opening a case automatically deletes all previous task_sla…

Re-opening a case does not delete existing task_sla records; the SLA engine retains them and creates new instances for the new open period. Deletion would destroy audit history. This option is tempting because a clean slate sounds tidy, but that behaviour belongs to manual record cleanup, not the SLA engine.

Trap 2: Active SLAs are automatically resumed from their exact previous…

Re-opening generates new task_sla records rather than resuming the paused ones; the prior instances remain attached to the earlier open period. The engine starts fresh calculations from the re-open time. Resuming from a pause point is what happens during a normal pause condition, not a case re-open.

Trap 3: The system prevents cases from being re-opened if an SLA has…

The SLA engine places no such restriction; a case can be re-opened regardless of whether its SLA breached, and new task_sla records are created for the new period. Blocking re-opens would contradict standard case lifecycle behaviour. This is tempting because breached SLAs feel final, but breach state does not gate re-opening.

A
If start conditions are met upon re-opening a Case, a new Task SLA instance can be automatically generated.
On re-opening, the SLA engine re-evaluates start conditions; if they are met again, it creates a fresh Task SLA instance rather than resuming the prior one. This satisfies the stem's scenario by generating new SLA tracking for the reopened Case.
B
Re-opening a case automatically deletes all previous task_sla records to maintain a clean slate.
Why it fails: Re-opening a case does not delete existing task_sla records; the SLA engine retains them and creates new instances for the new open period. Deletion would destroy audit history. This option is tempting because a clean slate sounds tidy, but that behaviour belongs to manual record cleanup, not the SLA engine.
C
Previously completed SLAs are preserved for historical audit and reporting purposes.
The SLA engine retains completed Task SLA records when a Case reopens, rather than deleting or overwriting them, so historical breach and duration data remain queryable. This satisfies the stem's audit and reporting requirement for re-opened Case scenarios.
D
Active SLAs are automatically resumed from their exact previous pause point without generating new instances.
Why it fails: Re-opening generates new task_sla records rather than resuming the paused ones; the prior instances remain attached to the earlier open period. The engine starts fresh calculations from the re-open time. Resuming from a pause point is what happens during a normal pause condition, not a case re-open.
E
The system prevents cases from being re-opened if an SLA has breached.
Why it fails: The SLA engine places no such restriction; a case can be re-opened regardless of whether its SLA breached, and new task_sla records are created for the new period. Blocking re-opens would contradict standard case lifecycle behaviour. This is tempting because breached SLAs feel final, but breach state does not gate re-opening.

Question 2hardmulti select

Which TWO scenarios represent valid use cases for the Customer Relationship [customer_relationship] table rather than the standard Account Parent field? (Choose two.)

Trap 1: Assigning individual contacts to accounts.

Contact-account links use the contact table's account field.

Trap 2: Creating a simple corporate headquarters to regional subsidiary…

A headquarters-to-subsidiary tree is exactly what the Account Parent field models, giving a single direct parent per account. The Customer Relationship table exists for many-to-many or role-qualified links, such as one account relating to several others with distinct relationship types.

Trap 3: Linking consumers to business accounts.

The Customer Relationship table links account records to other account records; consumers are stored as Contacts, not Accounts, so no account-to-account relationship can be created. It is tempting because business-to-consumer structures feel hierarchical, but that linkage belongs on the Contact's Account field.

A
Assigning individual contacts to accounts.
Why it fails: Contact-account links use the contact table's account field.
B
Creating a simple corporate headquarters to regional subsidiary tree structure.
Why it fails: A headquarters-to-subsidiary tree is exactly what the Account Parent field models, giving a single direct parent per account. The Customer Relationship table exists for many-to-many or role-qualified links, such as one account relating to several others with distinct relationship types.
C
Establishing peer relationships or joint ventures where neither account is a strict subsidiary of the other.
The Customer Relationship table models many-to-many links between accounts, so it suits peer or joint-venture arrangements where neither party is a subsidiary. The Account Parent field only expresses a strict hierarchical parent-child relationship, which cannot represent these reciprocal associations.
D
Defining a partner organization that provides support across multiple independent customer accounts.
The Customer Relationship table supports many-to-many links, so one partner can be associated with several independent accounts simultaneously. The Account Parent field permits only a single hierarchical parent per account, which cannot express this cross-account support model. This satisfies the stem's requirement for scenarios beyond simple hierarchy.
E
Linking consumers to business accounts.
Why it fails: The Customer Relationship table links account records to other account records; consumers are stored as Contacts, not Accounts, so no account-to-account relationship can be created. It is tempting because business-to-consumer structures feel hierarchical, but that linkage belongs on the Contact's Account field.

Question 3mediummulti select

An administrator is setting up account and contact management in ServiceNow CSM. Which TWO of the following statements are true regarding the relationship between accounts and contacts? (Choose two.)

Trap 1: Deactivating an account automatically deactivates all associated…

Deactivating an account does not automatically cascade deactivation to associated contacts unless a custom Business Rule is created.

Trap 2: An account must have at least one primary contact designated at all…

Accounts are not strictly required to have a designated primary contact to remain active or create cases.

Trap 3: Contacts inherit all roles and permissions of their parent account…

Roles and permissions are assigned to user/contact records individually or via profile assignment, not inherited purely from the account.

A
Deactivating an account automatically deactivates all associated contact records in the system.
Why it fails: Deactivating an account does not automatically cascade deactivation to associated contacts unless a custom Business Rule is created.
B
An account must have at least one primary contact designated at all times for case creation.
Why it fails: Accounts are not strictly required to have a designated primary contact to remain active or create cases.
C
Contacts inherit all roles and permissions of their parent account automatically without user record configuration.
Why it fails: Roles and permissions are assigned to user/contact records individually or via profile assignment, not inherited purely from the account.
D
A single contact can be associated with multiple accounts using contact relationships or multiple contact-account mappings.
ServiceNow supports many-to-many contact-account associations through contact relationships and the contact-account mapping table, so one individual can serve several organisations. This satisfies the stem's requirement for a true statement about account-contact relationships, since the model is not restricted to a single account per contact.
E
A contact record is stored as a record on the sys_user table with a reference to the customer account.
Contacts extend the sys_user table, so each contact is a sys_user record carrying a reference field (typically account) pointing to its customer account. This satisfies the stem's account-contact relationship constraint, letting one account own many linked contact records.

Question 4easymultiple choice

An administrator needs to configure Customer Service Management so that service requests can be submitted by individual consumers who do not belong to a corporate account. Which record type should be used to represent these individual customers in the system?

Trap 1: Account

An Account represents a corporate organisation with which multiple contacts are associated, so it cannot model an individual consumer lacking a company. The scenario explicitly excludes corporate accounts. Accounts would be correct when the customer is a business entity requiring its own hierarchy of contacts and entitlements.

Trap 2: Contact

A Contact represents an individual person, but in Customer Service Management contacts must belong to an Account, so a consumer with no corporate account cannot be modelled this way. The scenario requires a record type that stands alone. Contacts would be correct for employees or individuals tied to a business account.

Trap 3: Partner

A Partner record represents an external business relationship, such as a reseller or supplier, not an individual consumer submitting requests. The scenario requires representing a person with no corporate affiliation. Partner would be correct when modelling a channel or vendor organisation that interacts with the service operation.

A
Consumer
The Consumer record type represents individual customers who are not affiliated with a corporate account, enabling them to submit service requests directly. This satisfies the stem's requirement for individual consumers outside corporate accounts, unlike Business Account or Contact records.
B
Account
Why it fails: An Account represents a corporate organisation with which multiple contacts are associated, so it cannot model an individual consumer lacking a company. The scenario explicitly excludes corporate accounts. Accounts would be correct when the customer is a business entity requiring its own hierarchy of contacts and entitlements.
C
Contact
Why it fails: A Contact represents an individual person, but in Customer Service Management contacts must belong to an Account, so a consumer with no corporate account cannot be modelled this way. The scenario requires a record type that stands alone. Contacts would be correct for employees or individuals tied to a business account.
D
Partner
Why it fails: A Partner record represents an external business relationship, such as a reseller or supplier, not an individual consumer submitting requests. The scenario requires representing a person with no corporate affiliation. Partner would be correct when modelling a channel or vendor organisation that interacts with the service operation.

Question 5mediummultiple choice

An agent is trying to add a new contact to an account, but the contact already exists as a user in the system linked to a different account. What is the correct procedure to handle this scenario in CSM?

Trap 1: Delete the existing user record and create a new one

Deleting the user record destroys its history and linked relationships, and the contact must remain associated with its original account. CSM expects the existing contact to be linked to the new account through the customer relationship rather than duplicated. Deletion would be correct only for genuinely obsolete records with no dependencies.

Trap 2: Change the Account field on the existing contact record directly

Overwriting the Account field severs the existing relationship and breaks the other account's data integrity, since a user record can hold only one account association. Editing the field is tempting as a quick fix, and would be valid only when the contact genuinely belongs to the new account.

Trap 3: Convert the contact into a consumer

Converting a user to a consumer strips its account linkage and reassigns it a different record type, so the contact cannot remain tied to the original account as required. It is tempting because consumers represent contacts without account association, which suits genuinely account-independent individuals rather than shared users.

A
Delete the existing user record and create a new one
Why it fails: Deleting the user record destroys its history and linked relationships, and the contact must remain associated with its original account. CSM expects the existing contact to be linked to the new account through the customer relationship rather than duplicated. Deletion would be correct only for genuinely obsolete records with no dependencies.
B
Change the Account field on the existing contact record directly
Why it fails: Overwriting the Account field severs the existing relationship and breaks the other account's data integrity, since a user record can hold only one account association. Editing the field is tempting as a quick fix, and would be valid only when the contact genuinely belongs to the new account.
C
Convert the contact into a consumer
Why it fails: Converting a user to a consumer strips its account linkage and reassigns it a different record type, so the contact cannot remain tied to the original account as required. It is tempting because consumers represent contacts without account association, which suits genuinely account-independent individuals rather than shared users.
D
Associate the existing contact to the new account using the Account Contact relationship
The Account Contact relationship lets one contact link to multiple accounts, so the existing user contact can be associated with the new account without duplication. This satisfies the scenario while preserving the contact's existing account linkage.

Question 6mediummultiple choice

A CSM implementation specialist needs to restrict a knowledge base so that only users with the 'knowledge_admin' role can create and edit articles, while all other users can only read published articles. Which configuration should the specialist apply?

Trap 1: Set the knowledge base's 'Owner' field to the knowledge_admin group.

Setting the Owner field designates a group or user responsible for the knowledge base, but it does not enforce write restrictions. Ownership is used for notifications and reporting, not access control. It would not prevent non-admins from creating or editing articles. Therefore, this configuration fails to meet the requirement of restricting write access to only knowledge_admin role users.

Trap 2: Modify the knowledge base's 'Read' access to exclude all non-admin…

Modifying read access would prevent non-admins from viewing articles, which contradicts the requirement that all other users can read published articles. The scenario specifically allows read access for everyone, so restricting read would be incorrect. Access control for contribution is separate from read access, and this option addresses the wrong permission.

Trap 3: Add a before insert business rule on the kb_knowledge table that…

While a business rule could enforce restrictions, it is a custom code approach rather than using built-in access controls. The requirement is best met with declarative user criteria, which are easier to maintain and less error-prone. Additionally, a before insert rule would only affect inserts, not edits, and might not cover all write operations, making it incomplete.

A
Set the knowledge base's 'Owner' field to the knowledge_admin group.
Why it fails: Setting the Owner field designates a group or user responsible for the knowledge base, but it does not enforce write restrictions. Ownership is used for notifications and reporting, not access control. It would not prevent non-admins from creating or editing articles. Therefore, this configuration fails to meet the requirement of restricting write access to only knowledge_admin role users.
B
Modify the knowledge base's 'Read' access to exclude all non-admin users.
Why it fails: Modifying read access would prevent non-admins from viewing articles, which contradicts the requirement that all other users can read published articles. The scenario specifically allows read access for everyone, so restricting read would be incorrect. Access control for contribution is separate from read access, and this option addresses the wrong permission.
C
Add a before insert business rule on the kb_knowledge table that checks if the current user has the knowledge_admin role.
Why it fails: While a business rule could enforce restrictions, it is a custom code approach rather than using built-in access controls. The requirement is best met with declarative user criteria, which are easier to maintain and less error-prone. Additionally, a before insert rule would only affect inserts, not edits, and might not cover all write operations, making it incomplete.
D
Create a user criteria record that includes only the knowledge_admin role and apply it to the knowledge base's 'Can contribute' field.
The 'Can contribute' field on a knowledge base accepts user criteria, which defines who can create and edit articles. By creating user criteria that includes only the knowledge_admin role and applying it, only those users can contribute, while others can still read published articles if read criteria allow. This precisely meets the requirement.