Select Two (Multi-Select) Questions

HR Tasks

Why it fails: HR Criteria determine which HR Profiles and HR Templates apply to a worker; HR Tasks are generated by business process configuration, not filtered by criteria. It is tempting because tasks relate to HR workflows, but criteria would correctly control task assignment only indirectly through profile-driven process triggering.

HR Templates

Why it fails: HR Criteria select which HR Profiles apply to workers; templates are chosen by profile or business process configuration, not directly by criteria. It is tempting because templates shape HR records, but criteria would be the correct control when defining which profile set a worker receives.

HR Profiles

Why it fails: HR Profiles are the records that HR Criteria evaluate against, not the items criteria control. Criteria determine which employees are eligible for a service or which template applies. They govern eligibility and template selection, not the profile data itself.

UI Policy disabling

Why it fails: A UI policy only hides or makes fields read-only on the form; it does not stop data being read or exported through APIs, reports or list views, so leakage persists. It is tempting because UI policies genuinely enforce field-level behaviour for form users, and would be right when the goal is restricting what agents can edit or see on a record form.

Global table renaming

Why it fails: Global table renaming alters schema metadata and has no bearing on HR data leakage; it neither restricts access nor masks records. It tempts because renaming sounds like obfuscation, but leakage prevention relies on role-based access, field-level encryption and data masking in Microsoft Entra ID-governed systems.

Assignment Rules

Why it fails: Assignment rules route task and case records to fulfilers; they do not categorise, publish or surface knowledge articles, so the knowledge base functions without them. They are tempting because assignment rules are the correct choice when automating HR case routing, but knowledge base operation instead requires article categories, a knowledge base record and user criteria.

HR Service records

Why it fails: HR Service records store individual employee cases and requests, not the categorised articles the knowledge base serves, so they are not a required component. They are tempting because linking articles to services aids deflection, but that is the correct choice when configuring service-specific knowledge, not for base functionality.

An external API key

Why it fails: Creating an HR Service requires no external API key; authentication to third-party systems is irrelevant to defining the service itself. It is tempting because outbound integrations such as payroll or benefits providers do use API keys, and an API key would be correct when configuring a REST integration or credential record for such an external endpoint.

A custom database table

Why it fails: HR Services are built from ServiceNow's HR Service Configuration and associated record producers, not bespoke database tables; a custom table adds no required component. It is tempting because custom tables underpin many platform customisations, and they would be the right choice when persisting entirely new data entities that no existing ServiceNow table models.

User password field

Why it fails: The Lifecycle Event case form captures HR lifecycle data such as employee type, rehire eligibility and effective dates, not authentication credentials. Password fields belong to the User record, managed through identity settings. It tempts because lifecycle events trigger account provisioning, but the form itself stores no password attribute.

System properties configuration

Why it fails: System properties configuration governs platform-wide field behaviour and metadata settings, not the fields presented on a Lifecycle Event case form. It is tempting because system properties do appear in HR administration menus, and would be correct when an administrator needs to change global case behaviour rather than identify form contents.

HR Cases

Why it fails: Used for tracking, not discovery.

Assignment Rules

Why it fails: Internal routing logic.

HR Profile

Why it fails: Used for personal data.

Portal selection

Why it fails: Portal selection determines where a case is submitted, not the assignment logic that picks an assignee. It is tempting because portals can carry default assignment settings, and would be correct if the question asked how cases are created or categorised rather than how they are routed to people.

User locale

Why it fails: User locale governs language and formatting, not which HR agent or group a case routes to. It is tempting because locale appears in assignment-related configuration, and would be correct if routing depended on regional language skills rather than assignment rules, groups and case fields.

Assignment Rules

Why it fails: Assignment rules route tickets to fulfilers after submission; they do not determine service visibility. It tempts because both are HR administration constructs, but visibility requires user criteria referencing user attributes, whereas assignment rules act on task routing once a case already exists.

Service Portal

Why it fails: Service Portal is the end-user interface that renders visible services; it does not evaluate HR criteria. It tempts because portal configuration influences what users encounter, but visibility is governed by user criteria records matched against the user's profile, not by the portal itself.

Catalog Items

Why it fails: Catalog items are the published offerings users order, not a visibility filter; HR criteria are built from user criteria records such as department, location or role. It tempts because catalog items do appear in HR service configuration, but they control what is requestable, not who can see the service.

Employee Name

Why it fails: Employee names identify individuals but are directory attributes, not sensitive HR data categories such as health, financial or disciplinary records. It is tempting because names appear throughout HR systems and are personal data under privacy law, yet the sensitive categories require a special-category attribute, which a name alone lacks.

Case Description

Why it fails: A case description is narrative context recorded within an HR case record, not a standalone sensitive data category such as health, financial, or biometric information. It is tempting because case notes often contain sensitive details, but the category classification applies to the underlying data types, not the free-text field holding them.

It replaces roles entirely

Why it fails: HR Criteria supplement role assignment by filtering which identities qualify for a role; they do not remove roles, which remain the authorisation construct. It tempts because criteria do narrow who receives access, and where a design replaces static role membership with attribute-based selection it would be the correct choice.

It is hard-coded

Why it fails: HR criteria are configurable per tenant through the HR Criteria configuration object, so they are not hard-coded; administrators define and edit them. The statement describes fixed compiled logic, which applies to system attributes rather than criteria. Configurability is precisely what lets organisations tailor criteria to their own HR data.

It only works for the portal

Why it fails: HR Criteria are evaluated during identity processing for any source, including authoritative applications and delimited file feeds, so restricting them to the portal misstates their scope. It tempts because portal-based HR sources are a common deployment, and if the question concerned only portal-driven aggregation it would be correct.

Change Management

Why it fails: Change Management belongs to IT Service Management, governing IT infrastructure changes, not HR service delivery content. HR Service Delivery comprises components such as HR case management, knowledge bases and employee service centres. Change Management would be correct when scoping ITSM processes for IT change control.

Asset Tracking

Why it fails: Asset Tracking belongs to IT Asset Management within ITSM, tracking hardware and software inventory, not HR service delivery. HR Service Delivery covers case management, HR knowledge and employee portals. Asset Tracking would be correct when implementing IT asset lifecycle governance rather than employee HR services.

Incident Management

Why it fails: Incident Management belongs to ITSM/ITIL, not HR Service Delivery, whose components are Case and Knowledge Management, Employee Centre and HR services. It is tempting because HR cases can resemble tickets, and Incident Management would be the right component when resolving IT service disruptions rather than employee HR requests.

itil

Why it fails: The itil role supports IT service management processes and grants no HR case access. It is tempting because it is a common baseline role in ServiceNow, but it is intended for ITIL process users, whereas HR Agents need the HR Agent role and HR core application roles to open and manage HR cases.

sn_hr_core.admin

Why it fails: sn_hr_core.admin administers HR application configuration, not day-to-day agent case handling. It is tempting because it contains 'admin' and appears HR-specific, but it is designed for HR system administrators managing the HR application, whereas an HR Agent requires the HR Agent role and supporting HR core roles.

admin

Why it fails: The admin role grants broad platform configuration privileges and is not required for an HR Agent's case work. It is tempting because administrators can perform agent tasks, but the role is intended for system configuration, whereas HR Agents need the HR Agent role plus the HR core application roles scoped to their duties.

Incident table

Why it fails: The Incident table sits in the global scope, not sn_hr_core, because incident management is an IT service management process shared across the platform. It is tempting because HR employees raise issues that resemble incidents, but those are captured as HR cases. The sn_hr_core scope holds HR-specific tables such as case, task and profile.

Problem table

Why it fails: The Problem table resides in the global scope, not sn_hr_core, because problem management spans all applications rather than HR-specific processes. It is tempting since HR cases can generate problems, but scoped HR applications store their own case, task and related HR tables. Incident, problem and change records remain in global scope.

Assigning 'public' to all HR tables.

Why it fails: Setting HR tables to 'public' grants every user read access, exposing salary and personal records. It is tempting when broad self-service reporting is wanted without building ACLs, and would be correct only for genuinely non-sensitive reference tables such as public holiday calendars.

Sharing passwords between HR admins.

Why it fails: Password sharing removes individual accountability and defeats audit trails, so it cannot secure HR data. It is tempting as a convenience measure when multiple admins need the same privileged account, and would only be defensible where a documented break-glass shared credential exists under strict vaulting controls.

Only works for approvals

Why it fails: 'Wait for completion' applies to any activity containing child tasks or subflows, not solely approvals. It is tempting because approvals are the most visible blocking activity, and it would be correct if the option described a setting restricted to approval activities rather than the general wait behaviour.

Forces case closure

Why it fails: 'Wait for completion' pauses the activity until its child tasks or approvals finish, then resumes; it never closes the case. It is tempting because completion sounds terminal, and it would relate to case closure only if the activity itself were the final step before a separate closure action.

Is the default for all tasks

Why it fails: 'Wait for completion' is not the default; activities normally proceed asynchronously, so this misstates the baseline behaviour. It is tempting because synchronous execution feels like the safe assumption, and it would be correct where a workflow must block until an activity returns before continuing.

Assignment group

Why it fails: Assignment group controls which HR agents can view or act on a case, not which criteria determine HR Criteria visibility; visibility is driven by the criteria record's own configuration. It is tempting because assignment groups govern record access generally, and they would be correct when routing or restricting HR cases to a specific support team.

Incident status

Why it fails: Incident status tracks the lifecycle state of an incident record and plays no part in the HR Criteria visibility configuration, which uses criteria such as user criteria and department. It is tempting because status commonly filters lists and reports, and it would be correct when scoping an HR case list to only open or resolved incidents.

Service Desk phone

Why it fails: Service Desk phone is a support contact attribute, not an HR Profile field, which holds employment data such as job title. It is tempting because it is a user-record field, and it would be correct for service desk or contact configuration, not HR profile data.

IP Address

Why it fails: IP Address is a network attribute, not an HR Profile field, which stores employee data such as manager and department. It is tempting because it appears on user records, and it would be correct for network or device configuration, not HR profile data.

Field-level encryption can be enabled on any field by setting the 'Encrypted' attribute in the dictionary.

Why it fails: Field-level encryption is not enabled by simply setting an 'Encrypted' attribute. It requires the creation of an encryption context and the use of the 'Encryption' module in the platform. The 'Encrypted' attribute does not exist in the dictionary for this purpose. Encryption is typically applied through the 'Encryption' module and requires configuration of a key management service.

Encryption at rest can be applied to HR case attachments without any additional configuration.

Why it fails: This is false. While platform-level encryption may cover attachments, field-level encryption does not automatically apply to attachments. Attachments are stored separately and require their own encryption configuration, often through the same encryption context but with specific settings. Additional steps are needed to encrypt attachments.

Once a field is encrypted, users with read access to the record can view the decrypted value without additional roles.

Why it fails: This is false. Encrypted fields require specific decryption roles. Even if a user has read access to the record, they cannot see the decrypted value unless they have the appropriate decryption role defined in the encryption context. This separation of duties ensures that sensitive data is only visible to authorized personnel.

Workflow Execution

Why it fails: Workflow Execution is not a selectable Activity type in Lifecycle Events; activities are discrete actions such as creating a user account, generating a task, or updating an HR profile. It is tempting because workflows often underpin lifecycle processing, but a workflow is the orchestration container, not an activity configured within the event.

Catalog Item Order

Why it fails: Catalog Item Order is not an Activity type in Lifecycle Events; the valid set covers activities such as HR profile creation, user account provisioning, and task generation. It is tempting because ordering catalog items is a genuine Service Catalog operation, but that belongs to request fulfilment, not lifecycle event activity configuration.

The due date assigned to each HR task.

Why it fails: Due dates are used for tracking and escalation but do not influence when an activity starts. They are target dates for completion, not triggers. The system does not use due dates to sequence or delay activities; activities start based on their order and wait settings, not their due dates.

The audience type defined on the Activity Set.

Why it fails: The audience type determines who the Activity Set applies to, such as employees or contractors, but it does not control the timing of individual activities. Audience filtering affects whether the set is included for a given user, not the sequence or start time of activities within it. Timing is governed by activity order and wait conditions, not audience.

The priority level set on the Lifecycle Event.

Why it fails: Priority on a Lifecycle Event affects how the event is handled in terms of urgency, but it does not determine the execution timing of activities within Activity Sets. Priority may influence assignment or escalation but is not a factor in the sequential triggering of activities. Timing is controlled by activity order and wait flags.