I85PREP
⌘ K
ServiceNow CIS-CSM study materials
ServiceNow CIS-CSM study resources

The Surgeon Who Belongs to Two Hospitals

ServiceNow CIS-CSM · Put your knowledge to work in context.

All case studies

The Surgeon Who Belongs to Two Hospitals

Apex Medical Group is a parent account with four child hospital accounts. Dr. Lin, a surgeon, practises at two of them, so the data team created two contact records - same email address, different account. Cases arrive by email; an inbound email action matches the sender to a contact by email address and takes the first match. Roughly 15% of Dr. Lin's cases land on the wrong hospital, so the Gold entitlement never matches, the 4-hour SLA never attaches, and the customer portal shows the case to the wrong hospital's staff. A separate import added 2,300 duplicate contacts. Agents have started double-keying the account name onto every case, which has slowed average handling time by about three minutes.

1. Before changing any configuration, what would you verify to confirm the root cause, and in what order?

Read the worked answer

Separate three candidate causes before touching config:

  1. Matching order - the inbound email action picks the first contact by email address. Two rows match, one wins arbitrarily (often by sys_id or created date). This alone explains wrong contact on the case.
  2. Account derivation - check whether the case's account is copied from the contact's account or taken from the request context (mailbox, portal, service). If it is copied from the contact, the wrong contact guarantees a wrong account.
  3. Downstream effects - entitlement lookup then fails, so the Gold SLA definition never applies.

Order of checks:

  • Send one test email as Dr. Lin, inspect the resulting case: which contact, which account, which task_sla records exist.
  • Pull 20 known-misrouted cases and compare case.account against the sending contact's account and against the mailbox the mail arrived on.
  • Read the inbound email action's contact lookup condition and sort order.
  • Only then look at the entitlement and SLA definitions - they are symptoms, not the cause.

If the account is being sourced from the contact, no amount of duplicate cleanup fixes routing; the derivation rule has to change.

2. How should Dr. Lin be modelled so one person can serve two hospitals without duplicate contacts?

Read the worked answer

One person, one contact, several account relationships.

  • Keep a single contact record and relate it to both hospital accounts through the contact–account relationship model, with a role (for example, surgeon at Hospital A, consultant at Hospital B).
  • Do not use the account hierarchy to solve this. Hierarchy is a reporting and roll-up construct; it does not make a contact a member of a sibling account, and relying on it silently widens portal visibility to cases the person should not see.
  • Source the case account from the request context, not the person. The mailbox the email arrived on, or the portal the request was submitted from, tells you which hospital the request belongs to. Use that, then validate the contact is related to that account.
  • If the context is ambiguous, route to a triage queue that asks the requester which site the request concerns, rather than defaulting to the first contact match.

Test the fix with the same email sent to both hospitals' mailboxes and confirm different account values, different entitlements, and different SLA definitions.

3. What is the safe way to clean the 2,300 duplicates without breaking open cases and portal access?

Read the worked answer

Not all 2,300 are duplicates - classify first.

  • Match on normalised email plus name, but treat rows with the same person and different accounts as the multi-account pattern above, not as duplicates. Merging those would destroy exactly the relationship the business needs.
  • True duplicates: same person, same account.

For the true duplicates:

  1. Choose the survivor: the record with open cases, an active portal user, and entitlement history. Never the newest record by default.
  2. Build a mapping of duplicate → survivor and repoint first, merge second: cases, entitlement/contract references, portal user, and any custom references.
  3. Merge in batches of a few hundred with an audit trail, and keep the mapping so you can answer "where did case X go?" afterwards.
  4. Prevent recurrence: a duplicate rule on email + account, and a unique index or import validation on the integration that created them.

Do not run a bulk merge job and hope; portal users whose contact record disappears lose case visibility and raise new incidents.