The HR rollout looked great in the demo and stalled in week six. The complaint was the same from every department: “this feels like an IT ticketing system.” It is, because the project lifted the IT taxonomy, the IT lifecycle, and the IT vocabulary and renamed the categories. ESM at scale requires patterns that respect each function’s actual workflow.
Separate scopes, shared platform
Each non-IT service domain should live in its own scoped application — HR Service Delivery in HRSD scope, Workplace Service Delivery in WSD scope. Shared concepts (users, locations, knowledge bases) reference cross-scope but each domain owns its task table, its lifecycle, its forms. This isolates upgrades, permissions, and customization blast radius.
sn_hr_core (HRSD scope)
-> hr_case (extends task)
-> hr_lifecycle_events table
sn_facilities (WSD scope)
-> wsd_request (extends task)
-> wsd_floor_plan integrationLifecycle events, not incidents
HR does not work in incidents; HR works in employee lifecycle events — onboarding, promotion, parental leave, separation. Each event is a parent record orchestrating multiple child tasks across multiple groups. Modeling these as incidents loses the parent-child semantics and the audit chain. HRSD ships the right model out of box; resist the urge to “simplify” by mapping to incidents.
Vocabulary owned by the function
Field labels, status names, and notification templates should match the language the function actually uses. HR says “case,” not “ticket.” Facilities says “request,” not “incident.” Marketing says “project,” not “task.” Use the platform’s translation layer to override labels per scope without touching base tables. Vocabulary mismatch is the most reliable signal that ESM was bolted on rather than designed.
Confidentiality is the hardest difference
HR cases routinely contain medical, legal, or compensation data that IT cases never do. Apply ACLs at the table and field level; do not rely on assignment groups for confidentiality. Encrypted fields for sensitive attributes, audit trail visibility restricted to compliance roles, and a separate notification template that excludes sensitive content from email body. Default IT notification patterns will leak.
// ACL on hr_case.medical_notes (read)
user.hasRole('hr_medical_reviewer') ||
user == current.opened_forService Portal per function
The IT portal layout assumes IT use cases. The HR portal should look, feel, and read like an HR portal — different categories, different featured content, different intake forms. Use the multi-portal capability rather than building one mega-portal with conditional sections. Users should never see the IT-flavored portal when navigating from an HR notification.
Knowledge base separation with cross-references
Each function maintains its own knowledge base with its own taxonomy and approval workflow. Cross-references happen via explicit linking, not by mixing categories. An IT article on “VPN setup” can reference an HR article on “remote work policy” without merging the bases. Mixed bases make permissions and taxonomy collapse.
Common failure modes
Single assignment-group convention shared across all functions — HR groups end up visible to IT and vice versa. Single notification engine with IT-flavored templates — every HR email reads like an IT incident notification. Single SLA framework with IT semantics — HR cases do not have an SLA in the IT sense; they have lifecycle commitments. Use HRSD’s built-in HR Lifecycle SLA, not the standard one.
Implementation sequence
Stand up one non-IT function fully before adding the next. Get HRSD live with its own scope, portal, knowledge base, notification templates, and SLAs. Validate it for two months. Only then start the Facilities or Marketing rollout, copying the patterns that worked. Parallel rollouts of three functions usually produce three half-done implementations.
What to do this week: walk through your HR portal as an employee with no IT context — every IT-flavored word, icon, or category is a backlog item.
