Service Operations Workspace implementation is not a UI migration endeavor

[Sujit Agrawal]

Service Operations Workspace (SOW) can significantly modernize the agent experience: faster triage, cleaner navigation, and more context in fewer clicks. But implementations stumble because teams underestimate configuration dependencies, assume Classic behaviors will carry over, and over-customize early. If you plan for a few known challenge areas up front, you can deliver value quickly without creating upgrade debt.

Start with prerequisites and entitlements. SOW for ITSM depends on the right platform release and the correct Store/plugin enablement for the ITSM SOW applications. If dependencies are incomplete, you’ll see partial functionality: missing pages, actions that don’t appear, or inconsistent experiences across personas. Beyond enablement, align licensing expectations early—especially if stakeholders expect advanced capabilities (for example, recommendations, automations, or AI-adjacent features). A simple “bill of materials” (release + plugins + who is entitled to what) prevents late-stage surprises.

Next, treat “Classic parity” as a real workstream. The most common complaint in UAT is: “This worked in Classic.” Workspace experiences can differ, particularly around related-list interactions, cross-record actions (e.g., relating Incidents to Problems), record states (like closed records), and security-enforced behavior. Sometimes actions work but fail silently in Workspace due to how secure APIs or helper scripts execute in the workspace context. The best mitigation is to build a parity checklist for your top workflows (Incident, Major Incident, Problem, Change) and run it as a repeatable regression pack in SOW—not as ad hoc testing.

UI Builder configuration is often the biggest time sink. Many “broken workspace” issues are configuration-driven: missing or misconfigured UX screen records, incorrect page routing, or audiences that send the wrong persona to the wrong page. These problems can be amplified after upgrades, where UI Builder or workspace artifacts may behave differently, OOB records may be replaced, or previously stable layouts become hard to edit. To reduce churn, treat UI Builder artifacts as governed configuration: consistent naming, tight change control, and a clear promotion path from dev to test to prod. Also establish guardrails like “don’t delete OOB records,” and document any intentional deviations.

Avoid the “lift-and-shift” trap. Classic UI customization relying on specific client script behaviors, UI policies, or UI-driven show/hide logic—do not always map cleanly to Workspace. Trying to port those patterns can lead to unexpected behavior and rework during UAT. Instead, budget time to re-implement the high-value UI behaviors using workspace-appropriate mechanisms and accept that some user interactions will change (often for the better).

Finally, manage long-term risk: over-customization and upgrade fragility. SOW evolves quickly, and heavy layout overrides can cause performance challenges and block future out-of-the-box improvements and increase your regression burden on every patch and upgrade. Adopt a “configure over customize” principle, and for every customization document the rationale, impacted roles, regression tests, and rollback plan.

A practical next step is to create four lightweight artifacts: (1) prerequisites/licensing checklist, (2) Classic parity regression pack, (3) UI Builder governance and promotion approach, and (4) role/audience test matrix. Those deliverables keep your SOW rollout predictable, supportable, and upgrade-ready.