Entitlement Management practice questions

Service Contract Line Items

Why it fails: Service Contract Line Items record products and quantities covered under a contract; they do not decrement or display remaining case allowances. They are tempting because line items sit under the contract and describe purchased coverage, but case consumption tracking is held on the entitlement linked to the contract, which counts against its terms.

Milestone Processes

Why it fails: Milestone Processes define time-based actions on cases, such as escalation when a support milestone elapses. They do not count or limit case volumes. They are tempting because milestones attach to entitlements and contracts, but remaining case allowances are tracked through entitlement usage, not milestone timing logic.

Entitlement Templates

Why it fails: Entitlement Templates define reusable sets of entitlement fields and default values applied when creating entitlements; they hold no per-customer counter of consumed cases. They are tempting because templates standardise entitlement setup, but tracking remaining case allowances against a contract requires the entitlement's usage metrics, not a template.

Write an Apex trigger to manually instantiate the Milestone object when Case Priority is High.

Why it fails: Incorrect. Milestones are natively managed by Entitlement Processes without requiring custom Apex triggers.

Use an escalation rule to trigger the milestone when the Priority field is updated to High.

Why it fails: Incorrect. Escalation rules are separate from milestone tracking and cannot dynamically apply milestones to an active entitlement process.

Configure a validation rule to prevent cases from saving unless Priority is High.

Why it fails: Incorrect. Validation rules block saves; they do not control milestone applicability.

Configure Case Business Hours to exclude times when the status is 'Waiting on Customer'.

Why it fails: Incorrect. Business hours define operating hours, not case status-based pauses.

Create a Process Builder that pauses the Case Milestone record when status changes.

Why it fails: Milestone pausing is native behaviour driven by the milestone's own criteria on the Case Status picklist; Process Builder cannot pause a CaseMilestone record, as its timer is controlled by milestone configuration, not record edits. It tempts because Process Builder automates field updates and record creation, which suits unrelated Case automation.

Enable Milestone Recurrence to reset the timer whenever the status changes.

Why it fails: Recurrence restarts a milestone when its criteria are re-met after completion, so it resets rather than pauses the running timer, losing elapsed time. It tempts because recurrence handles repeating milestones such as reopening a case, where a fresh timer genuinely should begin.

Entitlement Processes

Why it fails: Incorrect. Entitlement processes define the actual lifecycle of a case milestone, not the initial account setup template.

Milestone Processes

Why it fails: Incorrect. Milestone processes define steps and timelines for cases, not account-level support templates.

Service Contracts

Why it fails: Incorrect. Service contracts track broader agreements, but templates specifically automate account associations.

Write a record-triggered flow to query and assign the entitlement.

Why it fails: Incorrect. A native setting handles this automatically without requiring a flow.

Configure an Entitlement Process rule for single-entitlement accounts.

Why it fails: Incorrect. Entitlement processes handle milestones, not auto-selection.

Use Macros to apply entitlements upon case open.

Why it fails: Incorrect. Macros are manual or semi-automated agent tools, not automatic backend bindings.

The previous milestone instance is permanently deleted from the database.

Why it fails: Incorrect. Historical milestone records are retained for audit and reporting purposes.

The milestone fails with a system error because recurrence is not supported for active processes.

Why it fails: Incorrect. Recurrence is a fully supported native feature.

The existing milestone timer is reset to zero and continues running.

Why it fails: Incorrect. Recurrence creates a new instance rather than resetting the exact same record if configured for multiple completions.

Changes to an active process automatically update all historical closed cases.

Why it fails: Incorrect. Historical closed cases are never retroactively altered by process updates.

Milestone types cannot be changed once created, even in draft processes.

Why it fails: Milestone types can be changed on draft entitlement processes; the restriction applies to active versions, where edits require a new version. It tempts because active processes are largely locked down, and that immutability would be the concern when altering a live process.

Draft versions can be activated while active versions have open cases without restriction.

Why it fails: Activating a draft version while the active version still has open cases is blocked; those cases must be closed or the process deactivated first. It tempts because versioning normally allows parallel drafts, and that freedom would apply to processes without in-flight case dependencies.

Entitlement Templates applied globally to Leads

Why it fails: Entitlement Templates applied to Leads cannot work: Leads are pre-conversion records without entitlement or contract relationships. Entitlement templates attach to Accounts, Contacts or Assets. This would be correct only if usage limits applied to lead records, which Salesforce entitlement management does not support.

Entitlement Process Assignment Rules in Omni-Channel

Why it fails: Entitlement Process Assignment Rules in Omni-Channel route work items to agents; they do not define contract entitlements. Time-based and usage-based limits are configured through Entitlements, Entitlement Templates and Entitlement Processes, so this component contributes nothing to tracking either limit type.

The milestone's success action requires a time trigger to be configured.

Why it fails: Success actions fire when the milestone is completed, which can be triggered by a case update or manual completion, not necessarily a time trigger. Time triggers are used for warning or violation actions. Requiring a time trigger for success actions is incorrect and would mislead a consultant troubleshooting this issue.

The case owner does not have the 'Manage Entitlements' permission.

Why it fails: The 'Manage Entitlements' permission controls setup and configuration access, not milestone execution. Milestone success actions run in system context and do not require the case owner to have that permission. This permission is relevant for administrators configuring entitlements, not for agents triggering milestones.

The milestone's success action is set to 'Set Field' but the field is not on the case page layout.

Why it fails: Page layout visibility does not affect whether a success action executes. The action updates the field value in the database regardless of layout placement. The agent might not see the change, but the action would still fire. This is a common misconception that confuses UI visibility with backend automation.

Friday at 8:00 PM, because the timer runs continuously once started.

Why it fails: The milestone timer does not ignore business hours; it pauses outside the configured business hours. Since the Entitlement Process uses 9 AM to 5 PM Monday through Friday, the timer would stop at 5 PM Friday and resume Monday at 9 AM, so 8:00 PM Friday is incorrect.

Monday at 9:00 AM, because the timer resets at the start of the next business day.

Why it fails: The timer does not reset; it pauses and resumes with the remaining time. After consuming 1 hour on Friday, 3 hours remain. Resuming Monday at 9 AM would cause expiration at 12:00 PM Monday, not 9:00 AM. The timer carries over the remaining duration.

Sunday at 4:00 PM, because the timer runs for 4 hours from creation regardless of business hours.

Why it fails: This option incorrectly assumes the timer runs continuously without regard to business hours. Entitlement Process milestones respect the business hours defined on the process, so the timer would not expire on Sunday; it would pause over the weekend and resume on Monday.

Configure the original entitlement process to have a milestone action that updates the case's entitlement and re-evaluates the process.

Why it fails: Milestone actions can update fields or send emails, but they cannot directly change the entitlement process on a case. Re-evaluating the process is not a standard action. This approach would not reliably stop the original milestones or start the new ones. The correct way to change milestones is to change the entitlement on the case and ensure the new process is applied.

Create a new entitlement process for the higher tier and use a workflow rule to update the case's entitlement to the new one when escalated.

Why it fails: Updating the entitlement on the case does not automatically stop the original milestones or start new ones. Milestones are tied to the entitlement process that was active when the case was created or when the entitlement was applied. Simply changing the entitlement may not trigger a new process unless the case's entitlement is reapplied, which could restart milestones but may not stop the original ones without additional configuration.

Use a before-save flow on the Case object to change the entitlement when the escalation field is updated, and ensure the new entitlement process is set to start on case edit.

Why it fails: While a flow can update the entitlement, the new entitlement process will only start if the case's entitlement is changed and the process is configured to start on case creation or edit. However, the original milestones may continue unless the case is re-evaluated. There is no standard 'start on edit' setting for entitlement processes; they are applied when the entitlement is first assigned. This approach may not stop the original milestones.

Use the 'Milestone Violation' standard report.

Why it fails: Salesforce does not provide a standard report named 'Milestone Violation'. Reporting on milestones requires a custom report type. Assuming a standard report exists is incorrect and would lead to a dead end. The consultant must create the necessary reporting infrastructure.

Enable field history tracking on the Milestone field on the Case object.

Why it fails: Field history tracking on the Milestone field would track changes to the milestone field value, but it does not capture violation events. Violation data is stored in milestone records, not in the case's milestone field. This approach would not provide the needed reporting data.

Set up a workflow rule to create a task when a milestone is violated.

Why it fails: A workflow rule creating a task would not provide a count of violations for reporting. It might alert someone, but it does not store violation data in a reportable format. Tasks are not ideal for counting violations over time. This does not meet the reporting requirement.

Create a milestone action that fires when the case is closed to manually stop the timer.

Why it fails: Milestone actions execute when a milestone is completed or violated, not when the case is closed. They cannot be used to stop timers based on case status. Success criteria are the proper mechanism to evaluate case closure and complete the milestone.

Enable recurrence on the milestone so it restarts when the case is closed.

Why it fails: Recurrence restarts a milestone when a case re-enters a specified status, typically used for reopens. It does not stop timers or mark milestones complete upon closure. Enabling recurrence would cause the milestone to restart, which is the opposite of the requirement.

Use a workflow rule to set the milestone status to 'Completed' when the case is closed.

Why it fails: Milestone status is managed by the Entitlement Process engine, not by workflow rules. Workflow rules cannot directly update milestone records. Success criteria are evaluated automatically by the system to determine milestone completion, making them the correct tool.

Use a formula field on the case to calculate the time difference and adjust milestone timers accordingly.

Why it fails: Formula fields cannot adjust milestone timers; milestone timers are controlled by business hours settings. This approach would not pause timers automatically and would require complex custom logic that is not supported. Standard business hours functionality should be used instead.

Create a separate business hours record for each time zone and assign it to the entitlement process.

Why it fails: Business hours are used to calculate milestone times, but they are not assigned to entitlement processes. They are assigned to entitlements or cases. Creating multiple business hours records is necessary, but they must be linked to the entitlement or case, not the process. This option misstates where business hours are applied.

Configure the entitlement process to use a 24/7 business hours record to ensure continuous tracking.

Why it fails: Using a 24/7 business hours record would not pause timers during non-business hours; it would keep them running continuously. The requirement is to pause during non-business hours, so a 24/7 schedule is the opposite of what is needed. This would lead to milestones being breached incorrectly.

Business hours are not assigned to the User profile.

Why it fails: Milestone timers run against the entitlement's business hours, but missing hours on the User profile do not stop milestones from being created — they only affect target calculations. It tempts because business hours govern milestone timing, yet the failure here is that no milestone record is generated at all.

The Entitlement is associated with a Service Contract instead of an Account.

Why it fails: Entitlements attach to Accounts or Products, not Service Contracts, so this association cannot exist as described. It tempts because Service Contracts also define support coverage, but milestone generation depends on the entitlement's channel and SLA, not on contract linkage.

The Entitlement Template has not been applied to the Contact record.

Why it fails: Entitlement Templates seed default entitlements when a Contact or Account is created; they are not applied afterwards to activate an existing entitlement. It tempts because templates sound like the assignment step, but the stem already states the entitlement is active and assigned, so template application is irrelevant.

Group Edition

Why it fails: Group Edition lacks the Service Cloud entitlement objects entirely, so Milestones and Entitlement Processes cannot be enabled there. It tempts because Group Edition does include basic Cases, making it look service-capable; entitlement management, however, requires Enterprise Edition or above.

Professional Edition only

Why it fails: Professional Edition does not include Entitlement Management; Milestones and Entitlement Processes need Enterprise Edition or higher. It tempts because Professional supports Cases and some service features, so organisations assume entitlements are bundled — they are not, and the objects are unavailable.

Contact Manager Edition

Why it fails: Contact Manager Edition has no Cases object at all, so entitlement objects and Milestones cannot exist. It tempts because it stores Accounts and Contacts, which look like the foundations of case management; entitlement management, however, requires Enterprise Edition or above.

Milestone Type

Why it fails: Milestone Type defines the template or category of a milestone, not entitlement expiry records, so it holds no per-user expiry dates to report on. It is tempting because milestones relate to entitlement lifecycle events, and would be correct when configuring which milestone templates apply to an entitlement process.

Service Contract

Why it fails: Service contracts track support agreements and their terms, not entitlement records with expiration dates, so querying them returns contract end dates rather than entitlement expiry. They are tempting because contracts also have start and end dates, and would be the right object when reporting on agreement renewals.

Case Milestone

Why it fails: Case milestones record the elapsed time against entitlement process steps on a case; they carry no expiry date for the entitlement itself. They are tempting because milestones are tied to entitlements and have target dates, and would be the correct object when reporting on milestone completion or breach.

Create a single Entitlement Process and use assignment rules to change the SLA timers dynamically.

Why it fails: Entitlement Processes define milestone timers per process; a single process cannot swap SLA targets dynamically via assignment rules, which only route records. Separate processes per tier are required. Assignment rules suit case ownership routing, not milestone timing.

Configure multi-currency settings to scale the SLA target times.

Why it fails: Multi-currency settings govern monetary conversion for opportunity and case amounts, not SLA timing. Gold, Silver and Bronze tiers require separate Entitlement Processes with their own milestones. Multi-currency configuration is correct when an org sells across regions using different currencies.

Use workflow rules to update the milestone target time based on the customer tier.

Why it fails: Milestone target times are set by the Entitlement Process and its milestones; workflow rules cannot recalculate them per tier. Distinct processes per support level are needed. Workflow rules suit field updates and notifications, not SLA milestone definition.

Milestone Type

Why it fails: Milestone Type defines the template for a milestone, such as first response or resolution, including its timing and actions; it stores no pricing, dates or covered products. It is tempting because milestones track support delivery, but the stem needs the agreement object itself, not the definition of a service-level step.

Entitlement Template

Why it fails: Entitlement Templates predefine milestone and entitlement defaults applied when entitlements are created; they hold no pricing, contract dates or covered products. The object is tempting because it governs support terms, but the stem requires a legally binding agreement record, which is the Contract object with entitlement linkage.

Entitlement Process

Why it fails: Entitlement Processes define the milestone sequence and escalation logic applied to an entitlement; they carry no pricing, contract dates or covered products. It is tempting because processes govern how support is delivered, but the stem asks for the legally binding agreement record, which is the Contract object.

To restrict when users are allowed to log into Salesforce.

Why it fails: Business Hours supply the calendar an Entitlement Process references when computing milestone due dates, not login restrictions. It is tempting because both involve time, but login hours are enforced per user profile or permission set, a separate mechanism entirely from entitlement milestone calculation.

To schedule weekly maintenance windows for the Service Cloud console.

Why it fails: Business Hours define the working schedule an Entitlement Process uses to calculate milestone target times, so they cannot schedule console maintenance windows. It is tempting because maintenance windows are also time-based, but those are configured through Salesforce release scheduling and console settings, not entitlement milestones.

To automatically send out-of-office email replies to customers.

Why it fails: Business Hours feed the Entitlement Process's milestone timer calculations, not outbound email autoresponses. It is tempting because both relate to availability, but out-of-office replies come from Email-to-Case autoresponse rules or Gmail/Outlook settings, not entitlement business hours.