Three COEs, One Portal: What Should Actually Separate the Work

Should carry the separation

• HR service - this is the routing-intent unit. Each COE owns its own HR services, and the HR template attached to each service defaults the case type, assignment group, and category. Cross-COE misrouting almost always traces back to a shared default assignment group on a template, or to one over-broad HR service whose routing is set ad hoc at case creation.
• Assignment group membership - the last line of defense. Even a misrouted case should be visible only to the group that owns it, which is what makes misrouting visible rather than silent.
• Case visibility option on the HR service - restrict case visibility so employees and agents outside the COE do not see records they have no business seeing.
• Knowledge base "Can read" criteria - knowledge separation belongs at the KB level, not at the portal page level.

Deliberately avoid

• Domain separation - the constraint already forbids it, and it solves a data-residency problem, not a routing problem.
• Catalog categories - presentation-only; they do not affect where a case lands.
• AD groups as the semantic boundary - membership drifts and carries no HR meaning. Use groups for portal/fulfillment access, not for deciding whose work this is.
• Keyword or subject-line routing rules - brittle, and they create the exact reassignment churn described here.

Diagnose in the order that eliminates the most possibilities per check:

1. Does a payroll/payslip article exist and is it Published with a Valid-to date in the future? Expired or draft articles are invisible to search regardless of everything else.
2. Which knowledge base is it in, and what are that KB's Can read user criteria? A very common configuration error is an HR knowledge base whose Can read list was cloned from an internal KB and still names only HR staff, so employees see nothing from it.
3. Article-level visibility / HR criteria targeting - if the article is scoped to an audience, confirm the searching employee matches it (this is where the 62% profile coverage starts to bite).
4. Search configuration - confirm portal search is actually reaching the HR knowledge bases (search sources / Employee Center search setup), not just a subset.
5. Vocabulary - short description and keywords; "payslip" vs "pay stub" vs "direct deposit advice."

Most likely outcome: the payroll article exists but is either expired or sits in a KB the employee cannot read, leaving the printer article as the only readable match. Confirm by impersonating a real employee and re-running the search, not by searching as an admin - admins bypass read criteria and will always see the article.

Why it matters operationally, not just analytically

HR criteria are evaluated against HR profile fields. A missing profile means criteria silently fail to match: targeted services, knowledge, catalog items, and lifecycle-event audiences simply do not appear for that population, with no error anywhere. It also means cases are created without department/location, so PA breakdowns go blank and assignment logic that keys off those fields degrades. The two acquired business units are almost certainly experiencing all three at once.

Remediation order

1. Fix the source, then backfill - import from the HR system of record with a coalesce key on user so re-runs update rather than duplicate. Never hand-create profiles in production.
2. Fix the creation trigger for new hires so the gap does not refill.
3. Add a standing data-quality report (active employees without an HR profile, profiles missing worker type/department/start date) reviewed weekly.
4. Only then re-test targeting - re-run audience previews on the lifecycle events and HR criteria for the affected business units.

Sequencing matters: tuning criteria before the data exists just moves the failure around.