ServiceNow's own Getting started with Core Business Suite article covers the fundamentals well: what CBS contains, the five setup steps (assign admins, configure your front door, activate priority modules, enable AI agents, train and monitor), and where to find docs and support.

What it doesn't cover is what actually happens once a request leaves the portal and starts moving between departments, and what that means for how you configure and govern it.

Note: This article is written against the Zurich release as the baseline.

How a request actually moves between departments

The "single front door" story is easy to picture from the employee side: submit once, get routed. What's less obvious is what happens on the back end when a request needs to move from, say, IT to Facilities.

• Universal Request isn't the ticket, it's the connector
  
  The number an employee sees (like UR0010001) never changes, even if their request bounces between three departments, but that's a label, not the actual record doing the work. Underneath it, the real ticket is still an HR Case, an IT Incident, or whatever record type that department normally uses, and that record is what actually gets handed off. Technically: when a request transfers departments, this underlying "Primary Ticket" changes, but the Universal Request number stays constant. Agents can see the full chain of prior tickets in the Associated Tickets list, but each department is still working in its own record type with its own fields, SLAs, and reporting. Universal Request sits on top, it doesn't merge them into one record.

• Employee tasking is a separate mechanism from department transfer
  
  "Send this to another department" and "ask the employee to do something" feel similar but are two different features. If a request needs the employee to take an action, for example upload a document or confirm a detail, that's handled through Universal Task, a distinct capability (available on higher-tier licenses, often called "Pro+") layered on top of Universal Request. It's easy to assume one setting covers both, but they're configured separately.

• Sensitive data boundaries need to be decided deliberately
  
  By default, a request that moves between departments can be seen by agents in both departments, which is a problem the moment an HR case about someone's medical leave or payroll issue becomes visible to an IT agent it was routed past. Universal Requests can be marked "restricted," limiting visibility to users with a dedicated sensitive-info permission. This isn't automatic. Someone has to decide which request types get flagged this way before go-live, not after the first sensitive case shows up in a shared queue.

What stays exactly where it was

CBS doesn't quietly absorb your other ServiceNow systems into one database. It's worth being explicit about this, since the marketing framing ("single intelligent experience") can imply more consolidation than actually happens: your incident data still reports through ITSM (IT Service Management), your HR Case data still reports through HRSD (HR Service Delivery), and ITOM (IT Operations Management) isn't touched by CBS at all. Universal Request adds a routing and visibility layer across these, but it does not replace the department-specific data, permissions, or reporting you already have. If your reporting currently lives in department-specific dashboards, plan for Universal Request analytics to sit alongside those, not instead of them.

 

The data model you're actually extending

Not every existing record type in your instance is automatically compatible with Universal Request. Only certain "families" of records are. If your organization built custom trackers for Legal or Facilities cases before CBS existed, those may need rework before they can plug in. Technically: the Universal Request table extends the base task table, which means only tables that also extend the task table are eligible to participate as a Primary Ticket. Custom case tables that don't extend the task table need to be re-architected before they can plug into Universal Request. This is a non-trivial migration for anyone with mature custom apps predating CBS, and it's worth scoping before you commit to a go-live date.

Activating Universal Request touches more than one department

Turning Universal Request on isn't a one-department decision, even if only one department asked for it. Why? Because it changes settings across the whole instance. Technically: installing the Universal Request plugin (com.snc.universal_request) activates a set of dependent plugins across the instance, including Agent Workspace (the interface agents use to manage tickets), Agent Assist Recommendation, Universal Request Reporting, and Service Catalog Workspace. In practice, this means the first department to adopt Universal Request is making an instance-wide change, not a department-scoped one. If IT already has a heavily customized Agent Workspace configuration, it's worth testing the plugin activation in a sub-production (non-live, test) instance first rather than assuming it's additive and isolated.

Creating Universal Requests outside the portal

Not every request has to start with someone filling out a form on the portal. You can also generate one automatically from an email or another system, which matters if a lot of your requests currently arrive that way. The UniversalRequestUtilsSNC scoped API (a set of backend functions developers can call, namespaced under sn_uni_req) exposes a createUniversalRequest() method. For example, converting an inbound email into an HR Case and a linked Universal Request in one script, rather than requiring the employee to resubmit through the portal. This is the pattern to reach for if you're consolidating existing email- or integration-driven intake into CBS rather than starting from a blank portal.

Testing has a gap worth knowing about

If your team wants to try CBS out safely before rolling it out for real, the free/sandbox environment ServiceNow provides for testing (a "PDI," or Personal Developer Instance) doesn't always have every feature turned on that production will have.

Now Assist for Setup (the guided, AI-driven configuration experience CBS's getting-started flow depends on) has not been consistently available on developer/PDI instances (this came up directly in the comments on ServiceNow's own getting-started article, and again more recently in a PDI-focused community survey). If your team is planning to prototype or train on a personal developer instance before touching a real sub-production environment, confirm Now Assist for Setup is actually present there first, rather than assuming your PDI mirrors what a production CBS rollout will look like.

What's new for AI in the Australia release

Everything above holds on Zurich. If you're already on, or planning to move to, Australia, two AI-specific additions change the shape of the conversation above:

• Employee Slate: A conversational front door, not a portal
  
  Powered by Moveworks, Employee Slate replaces the traditional Employee Center portal as the default entry point for new CBS customers: employees land in a chat-first interface that understands natural language instead of navigating topic pages. Existing customers keep their current Employee Center portal, as Employee Slate doesn't force a migration, but it's worth knowing this is now the default employees will see if you provision a new instance from scratch. Setup is guided directly from the CBS Foundation admin console, with both Moveworks and Now Assist configuration paths supported.

• L1 Autonomous Agents AI that closes tickets, not just routes them
  
  Where Zurich's AI largely classifies and routes, Australia introduces fully autonomous L1 help desk agents for HR, Workplace, Legal, Health & Safety, Finance, and Source-to-Pay. These are pre-built, activate from AI Agent Studio without a custom build, and run continuously, handling routine inquiries start to finish and escalating to a human only when a case is too complex or needs an exception. This is worth flagging clearly: as of the Australia release, this capability is in Restricted Access and requires ServiceNow product-team approval to activate, not something you can simply turn on. If you want to pilot it for a department, that means looping in your ServiceNow account team early, not budgeting it as a self-serve setup step.

Both of these change the "what does effective use look like" calculus above. An autonomous L1 agent closing HR cases end-to-end raises the sensitive-data question from the functional section earlier with more urgency, not less, since a misconfigured agent has no human in the loop to catch a restricted-data exposure before it happens.

What to decide before go-live, not during

• Write down your transfer policy. Which department types are allowed to hand a Primary Ticket to which others, and what data has to carry over when they do? This isn't configured by default, but it's a design decision.

• Decide your restricted-data policy up front. Identify which request types (HR, Legal, payroll-adjacent) need the sensitive-info restriction turned on before the first case crosses departments, not after something sensitive is visible where it shouldn't be. This becomes non-negotiable once autonomous agents are in the mix.

• Audit custom tables against the task extension requirement early. If Legal, Facilities, or another function is running on a custom table that predates CBS, this is the long-lead-time item. Start here, not at Step 3 of the setup guide.

• Treat the first plugin activation as an instance-wide event. Loop in whoever owns Agent Workspace configuration for your most mature module (usually IT) before the first department activates Universal Request.

• Use the API path for anything that isn't portal-native today. If HR or IT already receive a meaningful share of requests by email or integration, plan to hook into createUniversalRequest() rather than forcing a portal-only intake model that ignores how requests already arrive.

• If you want L1 Autonomous Agents, start the conversation with your account team now. Restricted Access approval isn't instant, so it belongs on the project plan early if end-to-end autonomous resolution is part of your CBS business case.

Two things worth being upfront about:

• Plugin dependencies, table relationships, and API behavior described here are accurate as of the Zurich release per ServiceNow's product documentation, but this kind of platform detail can shift release to release. Please verify against your own instance's release notes before treating this as gospel, especially if you're already on or moving to Australia.

• The Australia-specific items above (Employee Slate, L1 Autonomous Agents) are current as of the June 2026 CBS release notes. L1 Autonomous Agents in particular are explicitly called out as Restricted Access at time of writing, but that status could change, so confirm current availability with your ServiceNow account team rather than assuming it's generally available by the time you read this.

Who this is for, and who it isn't

CBS tends to be a strong fit if you're building several of these functions fresh, don't have years of customization to reconcile, and have someone who can actually own cross-department decisions once they come up. It's worth scoping more carefully first if you're layering it onto mature, heavily customized systems, running custom case tables that predate CBS, need deep department-specific depth CBS doesn't cover, or don't yet have anyone with the authority to make the shared calls this kind of platform forces into the open.