Hard Difficulty Questions

Define HR roles

Why it fails: This table stores topic categories that classify HR cases and requests, not role definitions. HR roles and responsibility assignments live in tables such as sys_user_role and sn_hr_core_profile. Choosing it here confuses categorisation metadata with access-control configuration.

Store HR cases

Why it fails: This table stores topic category definitions that classify HR cases, not the case records themselves. Actual HR cases are held in sn_hr_core_case and its task extensions. Choosing it confuses a reference lookup with the transactional case data.

Manage HR templates

Why it fails: The table holds topic categories used to classify HR cases, not template definitions. HR templates reside in sn_hr_core_template and related template tables. Selecting it mistakes a classification lookup for the record that drives case creation.

Assignment Rule

Why it fails: Assignment rules only handle routing.

HR Service

Why it fails: An HR Service is the container, but not the orchestrator itself.

Catalog Item

Why it fails: Catalog items are for single request fulfillment.

Using an Assignment Rule

Why it fails: Assignment rules do not attach documents.

Through a catalog variable

Why it fails: Variables are for inputs, not document links.

Via the HR Case Template

Why it fails: Templates do not hold document attachments.

Contextual Security

Why it fails: Contextual Security applies session-based conditions such as IP range or time of day to authorise access; it does not encrypt stored case data. It is tempting because it sounds like a data-protection control, yet it governs access decisions, not the at-rest encryption of HR case records.

Access Control Lists

Why it fails: Access Control Lists govern which users or roles may read or modify records; they do not encrypt stored data. They are tempting because ACLs are a familiar security control, but authorisation and encryption are separate mechanisms, and encryption at rest requires the platform's encryption property.

HR Criteria

Why it fails: HR Criteria defines the conditions a case must satisfy for assignment or workflow routing; it holds no encryption capability. It is tempting because criteria govern case handling, but encryption at rest is delivered through platform-level database or field encryption settings, not through case-matching rules.

Update the global ACLs for the topic table

Why it fails: ACLs are not the standard way to restrict portal content visibility.

Run the HR Criteria evaluation job manually

Why it fails: Evaluation jobs run automatically based on system schedules.

Set a Business Rule on the sys_dictionary table

Why it fails: You cannot secure data by modifying the dictionary definition directly.

Apply a UI Policy to make the field read-only

Why it fails: UI Policies are for client-side display, not data security.

Configure an HR Criteria record

Why it fails: HR Criteria is for record visibility, not field-level masking.

Portal Menu

Why it fails: Portal menus control navigation and page ordering; they do not group catalogue items with knowledge articles into browsable topic collections. A menu would be correct when defining which pages or links appear in the Employee Center header.

Catalog Category

Why it fails: Catalog categories organise catalogue items only; knowledge articles are grouped through knowledge bases and topic categories, so this cannot group both together. Categories would be correct when structuring request fulfilment items within a service catalogue.

Service Portfolios

Why it fails: Service Portfolios group offerings for governance and financial reporting, not for end-user browsing on the Employee Center. They fail here because the portal surfaces content through taxonomy-based Catalog Categories and Knowledge Bases. Portfolios would be the right choice when mapping services to business owners, cost centres, or compliance scopes.

By changing the scope of the cmdb_ci table

Why it fails: Changing a table's scope alters where it lives and which application owns it, breaking global table behaviour and other consumers; access is granted through roles and ACLs, not by moving the table. Scope changes suit moving a custom table into an application scope during development.

By adding the 'hr_admin' role to the table

Why it fails: Adding hr_admin directly to the cmdb_ci table grants that role access only within its own application scope; cross-scope access to a global table requires a cross-scope privilege record. It is tempting because role assignment is the normal access mechanism, but scope boundaries block it here.

By using an HR Criteria

Why it fails: HR Criteria filter which users a role assignment applies to; they cannot grant a role read access to a global table. Criteria are the right tool when conditionally assigning HR roles based on user attributes, not for cross-scope table permissions.

Service Catalog criteria

Why it fails: Service Catalog criteria govern which catalogue items a user can request, not portal content visibility, so they cannot conditionally render a banner. They are tempting because they do filter by user attributes such as location, and would be correct for restricting access to a catalogue item rather than a banner.

System property

Why it fails: A system property applies globally across the instance, so it cannot target the London office alone; it would show the banner to every employee. It is tempting because system properties are the standard mechanism for instance-wide settings, and would be correct if the banner were required for all users regardless of location.

Portal Menu

Why it fails: Portal Menu controls navigation entries and their ordering, not audience targeting by location, so it cannot restrict a banner to London employees. It is tempting because menus and banners both appear on the Employee Center, but conditional visibility requires audience or user-criteria configuration instead.

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.

Manually edit the profile

Why it fails: Manual editing bypasses the Lifecycle Event's automated attribute mapping, so the department change is not driven by the promotion data and can drift from the source of truth. Manual edits suit one-off corrections where no lifecycle event governs the record.

Use Trigger condition

Why it fails: A trigger condition only determines whether the lifecycle event fires; it cannot set the department attribute on the user record. Trigger conditions are tempting because they control event execution, and would be right when the promotion must meet criteria before the lifecycle process runs.

Update the activity set

Why it fails: The activity set defines the tasks executed when the lifecycle event fires; it does not itself carry the new department value into the user record. Updating it is tempting because activity sets orchestrate lifecycle processing, and would be right when the required actions or provisioning steps must change.

Apply a Business Rule to hide the field.

Why it fails: A Business Rule can set a field's visibility on a form, but it does not restrict underlying record read access — API, list and report views still expose Salary. Business Rules suit UI behaviour. The stem demands true field-level security, which read ACLs on the HR Profile enforce.

Implement a Data Policy to make the field read-only.

Why it fails: A Data Policy's read-only action still renders the Salary value to the partner team, merely blocking edits, so confidentiality fails. Data Policies are for masking or enforcing field behaviour across roles. The stem requires the field to be invisible, which field-level read ACLs on the HR Profile deliver.

Create an HR Criteria record for the Salary field.

Why it fails: HR Criteria records define conditions for HR profile creation and case routing; they carry no field-level read access semantics, so Salary remains visible. The option tempts because criteria sound like access scoping, but the correct mechanism is a field-level read ACL denying the partner role.

sys_user

Why it fails: Custom HR Profile fields syncing with payroll must extend the HR Profile table itself, since sys_user holds identity and login data, not employment records. sys_user is tempting because it is the natural home for user-linked attributes, and would be correct for fields like manager or department that genuinely belong to the user record.

sn_hr_core_config

Why it fails: Extending sn_hr_core_config alters HR profile configuration records, not the profile table itself, so a custom field would not sync with the payroll system. It is tempting because this table governs HR profile settings and layout options, making it the right choice when adjusting configuration behaviour rather than adding synchronised data fields.

sn_hr_core_case

Why it fails: sn_hr_core_case stores HR case records and their workflow state, not the HR profile fields that sync with payroll. It would be extended for custom case attributes, whereas profile data belongs on the HR profile table.

Assignment Rule

Why it fails: Assignment rules route records to users or groups after insert or update; they do not govern catalog item visibility. Visibility depends on user criteria, entitlement, and catalog conditions. Assignment rules would be the right choice for automatically setting the assigned_to field on a task or incident.

Business Rule

Why it fails: Business rules run server-side logic on database operations, so they cannot control whether a catalog item renders on the Employee Center. Visibility is determined by user criteria and catalog conditions. A business rule would be correct for enforcing data validation or field defaults on a record.

User Role

Why it fails: User role assignment governs access to the catalog item but not whether it appears on the Employee Center; catalog visibility is controlled by the catalog item's availability, user criteria and portal configuration. It tempts because permissions commonly cause missing items, and it would be correct if the item appeared but submission was blocked.

Client Script

Why it fails: Scripts are optional.

Approval workflow

Why it fails: Approvals are optional.

admin

Why it fails: Not best practice for agents.

itil

Why it fails: Not for HR.

sn_hr_core.basic

Why it fails: Too limited.

Data policy that enforces read access based on user's relationship to the case.

Why it fails: Data policies are used to enforce field-level rules, such as mandatory or read-only fields, but they do not control record-level access. They cannot prevent a user from reading a record. Data policies are not a security mechanism for record access; ACLs are the correct tool.

UI policy that makes the HR Case form read-only for users who are not the opener or assigned agent.

Why it fails: UI policies control the behavior of the form, such as making fields read-only or visible, but they do not restrict access to the record itself. A user could still view the record via a list or report. UI policies are client-side and not a security control for record access.

Before query business rule that filters the HR Case table based on user's relationship to the case.

Why it fails: A before query business rule can filter query results, but it does not secure individual records from direct access. A user could still access a record by its sys_id if they know it. Therefore, it does not provide the required record-level security. ACLs are needed to prevent unauthorized access to individual records.

The activity set is set to 'Active'

Why it fails: This is the required state.

The parent Lifecycle Event case is in 'Draft' status

Why it fails: Draft cases still process background logic.

The trigger condition is too complex

Why it fails: Complex conditions are supported by the platform.

Catalog Item Script

Why it fails: Catalog item scripts run on the Service Catalog request side, controlling variable behaviour and UI actions, not HR case creation. It is tempting because scripts execute during ordering, but the subflow must be attached to the HR service itself so it launches when the case is created.

Assignment Rule

Why it fails: Assignment rules route cases to support groups or individuals based on conditions; they execute no subflow. It is tempting because assignment logic fires on case creation, but the correct configuration is the HR service's flow definition, where the subflow is bound to the service.

HR Case Template

Why it fails: An HR case template pre-populates field values such as short description and priority; it carries no flow binding. It is tempting because templates are applied at creation, but the subflow is triggered by the HR service's flow configuration, not by template 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.