Core Business Suite (CBS): The fine print nobody mentions during the setup

[Wessel van Enk]

ServiceNow's own Getting started with Core Business Suite covers the fundamentals: what CBS contains, the five setup steps, and where to find docs. What it skips is what happens once a request leaves the portal and starts moving between departments, and what that means for how you configure and govern it.

How a request actually moves between departments

The "single front door" story is easy to picture from the employee side: submit once, get routed. Underneath, Universal Request is a connector, not the ticket and the number an employee sees (UR0010001) never changes, but the real record behind it (an HR Case, IT Incident, or whatever the department uses), does change, and that's what actually transfers between teams. Agents can see the full chain in the associated tickets, but each department still works its own record type, SLAs, and reporting. Getting the employee involved is a separate mechanism from handing the request to another department: "send to another department" and "ask the employee to do something" feel similar but are different features, with the latter handled by Universal Task, a distinct capability often gated to Pro+ licenses. And sensitive data needs a deliberate flag. By default, agents in both departments can see a transferred request, which becomes a problem the moment an HR case crosses into an IT queue, so request types that need the "restricted" setting should be identified before go-live, not after.

What CBS doesn't do automatically

CBS doesn't quietly merge your other systems into one database: incident data stays in ITSM, HR Case data stays in HRSD, and ITOM isn't touched at all, so plan for Universal Request's analytics to sit alongside your existing dashboards rather than replace them. It's also not compatible with just any table. Only tables that extend the base task table can serve as a primary ticket, so custom Legal or Facilities trackers built before CBS often need rework, which makes this a good candidate to scope early given the long lead time. Turning Universal Request on isn't department-scoped either: activating the plugin pulls in Agent Workspace, Agent Assist Recommendation, and other plugins across the whole instance, so it's worth testing in a sub-production instance first if your Agent Workspace is already heavily customized. Requests also don't have to start on the portal. The createUniversalRequest() method in the sn_uni_req API can generate one from an email or another system, which is useful if a meaningful share of requests already arrive that way. Finally, testing has a gap worth knowing about: Now Assist for Setup, which the getting-started flow depends on, hasn't been consistently available on developer (PDI) instances, so confirm it's actually present before planning to prototype there.

New in the Australia release

Two additions change the context above. Employee Slate is a Moveworks-powered conversational front door that's now the default entry point for new CBS customers, though existing Employee Center portals aren't forced to migrate. L1 Autonomous Agents are pre-built agents for HR, Workplace, Legal, Health & Safety, Finance, and Source-to-Pay that resolve routine cases end-to-end and escalate only exceptions. This has been described as Restricted Access requiring ServiceNow product-team approval, so it's worth confirming current status with your account team before building it into a project plan. An autonomous agent closing HR cases end-to-end raises the sensitive-data question above, not lowers it, since there's no human in the loop to catch a restricted-data exposure before it happens.

Decide before go-live, not during

A handful of decisions are worth making up front rather than discovering mid-rollout. Write down a transfer policy covering which departments can hand off to which, and what data has to carry over when they do. Decide which request types (HR, Legal, payroll-case) need the restricted-data flag before the first case crosses departments, not after something sensitive is visible where it shouldn't be. Audit custom tables against the task-extension requirement early, since this tends to be the longest-lead item on the list. Treat the first plugin activation as an instance-wide event, and loop in whoever owns Agent Workspace configuration for your most mature module before the first department switches Universal Request on. Use the createUniversalRequest() API path for anything that isn't portal-native today, rather than forcing a portal-only intake model onto requests that already arrive by email or integration. And if L1 Autonomous Agents are part of the plan, start the conversation with your account team now, since Restricted Access approval isn't instant.

Who this is for

CBS fits best if you're building these functions fresh, don't have years of customization to reconcile, and have someone who can own cross-department calls. Scope more carefully first if you're layering it onto mature, heavily customized systems, running pre-CBS custom case tables, or need department-specific depth CBS doesn't cover.

Accurate as of the Zurich baseline (Australia items per the June 2026 release notes); platform details shift release to release, so verify against your own instance.