The subsidiary that could read the parent's cases

A freight group opened its customer portal on a Thursday. By Tuesday a service manager at one of the subsidiaries had opened her case list and found eleven cases she had no business reading, two of them raised by a company her team had lost a tender to. Both firms sat under the same parent account, because the group had bought them eighteen months apart.

Nothing had failed. Somebody had set contact access to cover the account and everything beneath it, on the fair assumption that a hierarchy in a customer table describes one company. The group spent four weeks shaping that hierarchy for revenue reporting and about thirty seconds deciding who could read cases. The second decision was the one that reached a customer.

An account hierarchy in ServiceNow CSM records a commercial relationship, which entity sits under which and where the contract lives. Case visibility is a separate decision layered on top. The product lets you line the two up with a single field, and that convenience catches people out, because the reporting shape and the confidentiality shape are rarely the same.

What the account model actually holds

Accounts hold the companies you serve. Each account can point at a parent, which gives you the hierarchy, and children nest several levels deep. Contacts are the named people at those accounts who raise and read cases. Consumers are individuals you serve directly rather than through a company, and they attach to households and products instead.

Most business to business implementations never need a consumer, and some create them by accident when a plugin brings a registration path that can mint one. Check early. If your portal can create a consumer for someone who already exists as a contact, you end up with two identities for one person and only one of them carrying the cases.

Shape the hierarchy around the contract rather than the org chart on the customer's website. Where the parent signs and the subsidiaries buy under it, the parent belongs at the top. Where three sister companies sign separately under a holding company that buys nothing, putting them all beneath it earns a tidy rollup and a visibility problem for later. A shared customer record has to match the customer's own sense of who they are.

Three settings decide what a contact can read

Contact access comes down to three choices, set per contact. The narrowest shows a person only the cases they opened themselves, which suits a customer whose staff each handle their own tickets. The next shows every case at their own account, which is what most customers picture when they ask for a shared view. The third extends that reach down through the hierarchy.

The third one causes the incidents. A contact at a group parent reads cases from every entity beneath them, and some of those entities are businesses the customer considers separate, with their own boards and in regulated sectors their own supervisors. Nobody at the customer asked for that. Somebody at your end switched it on because the hierarchy already existed.

Default to account level for everyone, then grant hierarchy visibility one contact at a time to people the customer has named in writing. Ask the sponsor whether a given person at head office should read the cases raised by each named subsidiary, and take that answer rather than reading it off the hierarchy. A yes for some children and a no for others means per-contact handling rather than one blanket setting.

The partner who does not work for the customer

Reseller and managed service arrangements break the simple story, because the person raising the case does not work for the company that owns the product. A provider logs cases for forty clients. Their engineer needs the cases their firm raised for one client, without that client's internal cases and without sight of the other thirty nine.

ServiceNow covers this with partner contacts and a partner relationship between the accounts, so the engineer reaches the cases their firm handles for that customer while staying a contact of the provider. The customer's staff still see everything at their account, including the partner's cases. Set the engineer up as an ordinary contact at the customer instead and they inherit the entire case list, which is a contract problem.

Ask one more question during design. When the partner contract ends, what removes their access. If the answer depends on somebody remembering to deactivate a contact, write that check into offboarding now, because a lapsed partner with a live portal login is what an auditor puts near the top of the report.

Contact roles and the contact who changed employer

Access decides which cases a contact can see. Contact roles decide what they can do, and roles are the half that gets skipped. A contact who may open a case is a different person from the one who may approve a quote, close a case for their company, or administer the other contacts at their account.

The administrator role deserves its own conversation with the customer. Hand it to the wrong person and they can widen access for everyone at their account without telling you, so the model you agreed in design gets rewritten on a Friday afternoon by a customer employee. Some customers want that control and handle it well. Record the decision where the next admin will find it.

Then there is the contact who changes jobs inside the group. Someone at a subsidiary is promoted to the parent, an admin updates the account on their contact record, and everyone assumes access followed. Sometimes it does. What rarely moves is anything granted to that person individually, and every case they are already named on keeps them named on it.

That is the quiet failure. A contact named on an old case as the person who raised it usually keeps the link after the account change, so a new head office employee can still open their former employer's cases. Make the move a procedure rather than a memory. Review the old cases, decide which links stay, revoke individual grants, and check the new access matches the new employer. Give it the care you would give access request governance inside your own walls.

Entitlement checks read the install base

Entitlement rarely keys off the account alone. Most checks read the install base, the record of what the customer actually has, or the sold product behind it. Cases get routed, prioritised or refused on whether that asset is covered, so a contact can be entitled to log a case and still get a service level belonging to another site. Teams arriving from an internal service desk meet the boundary between ITSM and CSM here.

Install base records belong to one account, usually the one that took delivery. A parent contact with hierarchy visibility may see a child's cases while entitlement still evaluates against the child's assets, and the two models disagree in front of a customer. Group contracts are often bought centrally and consumed locally, and your configuration has to say which of those facts drives the check.

If the install base also feeds the configuration management database, the ownership story has to match on both sides. Running CSM and ITSM on one CMDB is a sound decision and a poor accident.

Impersonate a contact at a child account

Impersonation is the only honest verification. Reading the access field on a contact record and agreeing that it looks correct verifies your own intention and nothing else. Impersonating that contact and opening the case list shows what the platform returns, which is what the customer sees on the first morning.

Test from the bottom. Impersonate a contact at a child account, several levels down if your hierarchy goes that deep, and a partner contact if you have any. An admin impersonating another admin proves nothing, because admins see everything. The useful test is your narrowest user on the account furthest from the top, reaching for a case they should never reach and failing.

Before the portal opens to anyone real, sit down with the service desk lead and the customer sponsor and confirm every line below by impersonation rather than by configuration review.

  • A contact limited to their own cases cannot see a colleague's case at the same account.
  • A contact at a child account cannot open a case belonging to the parent or to a sibling company.
  • A contact with hierarchy access reaches only the child accounts the customer named in writing.
  • A partner contact sees the cases their own firm raised and nothing else at that customer.
  • A deactivated contact cannot sign in, and their cases stay attached to the account.
  • A contact moved to another account has lost access to the cases they raised at the old one.
  • Entitlement resolves against the install base for the site that raised the case.
  • Every line above was checked while impersonating the contact, not while signed in as yourself.