Tuition Reimbursement: Catalog Item, HR Service, or Both
Meridian has 1,400 employees and receives about 40 tuition reimbursement requests per quarter. The process requires a manager approval, then an HR benefits approval, a mandatory proof-of-enrollment upload, and three fulfillment steps: eligibility check, payment request to Finance, and a confirmation letter to the employee. Records must be retained seven years, and HR has published a 10-business-day service commitment. Today the process is a catalog item that creates only a request item and emails a shared mailbox. There is no case, no SLA, and no audit trail; employees call to ask for status. Finance will no longer accept email as the record of approval. The catalog item is currently visible to all active users, including contractors, who are not eligible. HR wants to keep the same portal tile.
1. Should this remain a catalog item or become an HR service that opens a case? Argue the decision, and state what you would keep from the current design.
Read the worked answer
Become an HR service that opens a case. The requirement set is the giveaway: a multi-step fulfillment chain with named owners, a two-stage approval that must be evidenced (Finance's objection), a published service commitment, and a seven-year retention obligation. A request item is an order record; it has no native task chain, no approval trail with the fidelity Finance wants, and no case-level SLA or agent workspace history. Reporting on cycle time and approver lag is also far cleaner from case and task records.
What to keep
- The catalog item stays as the ordering channel - the portal tile survives. Item submission routes into the HR service and creates the case; the request item is retained as the ordering artifact.
- The existing description text and attachment field naming so employees see no change.
What to change
- Route fulfillment onto case tasks instead of a shared mailbox, and record approvals on the case so Finance has an auditable, in-system approval. Retention is then a property of the case and its attachments rather than of a mailbox nobody owns.
Sanity check: if the process were a single-step, no-approval, no-audit request, the request item would be correct and a case would be overhead. It is the combination of approvals, tasks, SLA, and retention that forces the case.
2. List the configuration objects you would create or change, and identify the single most likely setting to break the 10-business-day commitment.
Read the worked answer
Objects
- HR service - case type, owning assignment group (Benefits), category, availability, and the case visibility option.
- HR template - program, term, requested amount, proof-of-enrollment as a mandatory attachment, default short description, and default assignment group so no case is ever created unrouted.
- Approval logic - sequential: manager, then Benefits. Sequential, not parallel; the Benefits approver should not be able to approve before the manager.
- SLA definition on the HR case: 10 business days.
- Three case tasks, each with its own owner and (where useful) a shorter internal target.
- Document/attachment requirement enforced on submit.
- HR criteria for eligibility (see next task).
Most likely SLA breaker
Not the duration - the schedule attached to the SLA. If it runs on a 24x7 schedule, a Friday-afternoon submission burns the weekend and the team sees phantom breaches; if it pauses on "awaiting employee" and nothing resumes it when the attachment arrives, the case silently never breaches again and the metric becomes meaningless. Verify both by walking a test case across a weekend and across an awaiting-info cycle before go-live. Second most likely: attaching the SLA to the task rather than the case, so total elapsed time is never measured.
3. Contractors can currently see and order the item. Would you use HR criteria or catalog user criteria to fix eligibility, and what is the failure mode of your choice?
Read the worked answer
Use HR criteria. Eligibility here is an HR attribute (worker type / employment type), not a portal-access attribute. HR criteria read the HR profile, so the same condition can be reused across the HR service, the related knowledge articles, and any future lifecycle-event audience - one definition, three consumers. Catalog user criteria can only reason about user record fields, groups, and roles, and contractors are typically sitting in the same AD "employees" group as everyone else, which is exactly how they got access in the first place.
Failure mode - and it is a real one
HR criteria against an HR profile field fail closed when the field is blank. With profile coverage imperfect, tightening eligibility this way can remove the item from genuinely eligible new hires whose worker type has not synced yet. Mitigations: confirm the worker-type field is populated for the population before enabling, add a monitored exception report for eligible-looking users with blank worker type, and decide explicitly whether the safe default is "deny and let them raise an inquiry" or a temporary allow-list.
Verification
Impersonate one employee, one contractor, and one employee with a blank worker type, and confirm the tile behaves as designed in each case.