[Platform Academy] Gatekeeper to Guide: Onboarding Your Business Process Owners into Catalog Builder

[tosinbells_sn]

Table of Contents

• Where the bottleneck comes from
• Gatekeeper and guide: two operating models
• Who a business process owner actually is
• The onboarding playbook
• The template is where the guardrails live
• Part 1 demo: David's first catalog item
• Sub-prod or production?
• Reusable question sets in Catalog Builder
• Part 2 demo: A workstation request that branches
• Best practices in catalog builder: a guardrail written in plain language
• Step-based request fulfillment
• Part 2 demo: David builds his own fulfillment and tests it
• Questions worth repeating
• Three things to do next

Where the bottleneck comes from

The math works against a small central catalog admin team that authors every single catalog item. Two things happen with this model and neither is good.

The team gets overwhelmed and devotes real capacity to building catalog forms. Or the team deprioritizes catalog authoring, and catalog items that should exist never get built. Either way, the business routes around the queue. Sensitive information ends up on a spreadsheet, in an email thread, or in a tool with no guardrails at all because end-users don't have a proper fulfillment path.

Unsurprisingly, when asked about the biggest hesitation in delegating catalog authoring, the in-session poll showed that catalog sprawl and inconsistency outranked security fears. The fear isn't that a process owner breaks something. It's that the catalog gets messy. Follow along to learn how to keep things orderly for your process owners to own their catalog items. 

Gatekeeper and guide: two operating models

Same team, same skills, very different outcomes.

The gatekeeper. Platform/catalog admins author every catalog item. Process owners submit requests and wait behind a backlog. The first build usually isn't right, so developers and business users trade revisions. The long tail never reaches the top of the list, and shadow processes fill the gap.

The guide. Process owners author within guardrails. Admins define templates that set what's possible and what isn't. The long tail finally gets built, and the catalog scales without added headcount.

Nothing about the guide model means less control. Control moves earlier, from reviewing every item after the fact to deciding what can be built before anyone starts.

Who a business process owner actually is

Someone who owns a service outside IT and handles requests that come with it. An HR benefits lead. A facilities coordinator. Someone in legal ops.

Two things make them the right choice.

They understand the process better than any admin can. However good a platform team is at configuring catalog items, nobody understands a facilities request process like an actual facilities coordinator. They know the nature of the request, they know the people they serve, and they know what to ask.

They feel the pain directly. Those requests are already part of their day. Fixing the process solves a problem that's theirs.

And the part worth stressing: they do not need to be ServiceNow practitioners. No certification, no platform background, no scripting. 

The onboarding playbook

Find your first three

Don't start with an organization-wide program. Start with three process owners who fit four traits: high request volume, a manual process today (email or a hand-maintained spreadsheet), low fulfillment risk with no complex integrations, and genuine willingness to partner.

• HR is a gold mine. New hire requests, name changes, tuition reimbursement. Form-heavy, and they don't drag adjacent processes with them.
• Facilities is manual and repetitive. Desk moves, access, equipment. Someone emails a coordinator today, which is a near-perfect catalog item candidate.
• Finance and ops have clear rules and clear intake, with low downstream impact.

Make the pitch they'll accept

Start with the process owner's problem, not the platform team's. They have the expertise. They can change the experience themselves rather than waiting in a queue. They know the process better than IT does, and saying so out loud is what earns trust.

Then disarm the fear before they raise it: no code, no scripts.

Run a repeatable loop

1. Identify and recruit. One owner who meets the criteria, one high-volume item.
2. Equip and delegate. Get them into Catalog Builder with a template and guardrails in place.
3. Co-build and coach. Build the first item together, then let them drive.
4. Govern and scale. Add governance, then recruit the next owner.

Step 4 is what turns one success into a program.

The template is where the guardrails live

This was the most practical stretch of Part 1, and it's worth reading closely, because the template is the entire safety story. Catalog Builder is a guided experience rather than a blank canvas, and the template is where an admin decides what "guided" means.

Working through a Facilities Request Template, the settings that matter:

• Name and description. The description is what the process owner reads to know whether this template is the right one. Write it for them.
• Scope. A checkbox restricts items created from this template to their own scope, keeping them out of global. Useful for some setups, optional for others.
• Catalog, category, topic, and taxonomy. Restrict where items created from this template can live. This is what keeps a new item from landing somewhere it disrupts a catalog another team maintains.
• Predefined question sets. Attach questions that should appear on every item built from this template, whether the author adds them or not.
• Behavior toggles. Hide Add to Cart, hide Save as Draft, hide the quantity selector.
• User criteria. The sharpest example from the session: a facilities manager in the US handles US offices only. User criteria controls both who can use the template and who can see the resulting items, so a US desk-move item never surfaces to someone in the UK with no context for why it exists.
• Pre-selected fulfillment flow. Choosing the flow at template level removes a decision the process owner shouldn't have to make. If the organization has a standard request fulfillment flow, or a specific one for procurement, select it once.
• Overrides. Define which questions the submitter can edit, which are mandatory, and which selections are restricted.

One notable question from the session: why no UI Actions setting at template level? Because UI Actions live on the catalog item itself. Templating them would mean anticipating every use case the author might need, and they're too dynamic for that.

Part 1 demo: David's first catalog item

David is a facilities coordinator. Desk-move requests reach him by email today, and he aggregates them by hand. He has never built anything in ServiceNow.

Setup: a group for process owners with catalog editor permissions, with David added to it.

The first thing visible when impersonating David is what he can't see. An admin opening Catalog Builder gets several options, including building an item from scratch. David gets exactly one: create a new catalog item with a template. The guardrail isn't a policy document. It's the absence of a button.

David picked the Facilities Request Template, chose to build with AI, and gave it a single prompt: create a desk move request for an employee moving to a new desk, including the employee moving, the new desk location, the requested move date, and whether help is needed moving equipment.

What came back:

• Correct variable types, unprompted. The employee field resolved to a user reference, the move date to a calendar field, and the equipment help question to yes/no. David never specified any of that.
• A live interactive preview. Earlier versions dropped straight into the edit view with no way to see the result. The current experience shows the rendered item beside the chat as it builds.
• The requester field defaulted to David, because he was the logged-in user.
• The template's questions came through anyway, mandatory as configured, whether or not the prompt mentioned them. Template beats prompt.

David then added a question by asking for one in plain language, and AI is available throughout the journey rather than only at first creation, so an existing item can be edited the same way.

Sub-prod or production?

The most-asked question in Part 1, and it deserves the full answer rather than a yes or no.

There's no recommendation of one approach over the other. Both are valid depending on the setup.

Sub-prod first. Process owners author in a sub-production instance, and the update sets move to production through the normal instance stack. This suits teams whose change process expects it.

Directly in production. With guardrails properly configured, this is a legitimate choice. Restrict where those users can write, restrict which users can see the resulting items, restrict which question sets are available. Set up properly, a process owner authors and publishes in production without a promotion cycle at all.

The reaction in chat was that production authoring sounds scary. The counter is that scariness is a function of scoping, not of the model. The candidate criteria do the work: the right kind of process owner, and low-risk catalog items with no impact on critical systems. Someone moving their desk to a different part of the office does not carry production risk. The real residual concern is sprawl, not impact.

Reusable variable sets / question sets in Catalog Builder

A question set is a named group of questions built once and attached to as many catalog items as needed. Three reasons it matters for delegation:

Faster to build. Requester, location, urgency are questions a facilities coordinator needs nearly every time. Calling one set beats rebuilding them from scratch.

Consistent by default. This is the real payoff, and it connects directly to the sprawl worry that topped the Part 1 hesitation poll. Part 1's demo used AI authoring without a question set, which meant each generated item could phrase shared questions slightly differently. Attach a question set to the template and those questions arrive pre-populated and identically worded every time, even when the item is generated with AI.

Restricted on purpose. Question sets also shape which questions are available to which groups of process owners, which makes them a delegation control and not just a time-saver.

Part 2 demo: a workstation request that branches

The scenario picked David back up with a harder build: a workstation setup request covering two work personas, remote and hybrid. Remote employees get equipment shipped home. Hybrid employees get it provisioned at their office space. Delivery must be at least four business days out.

Two question sets existed in advance: one for employee address, one for requester and manager. The Facilities template already carried the requester and manager set.

Built by prompt, in plain language, in this order:

1. The base item. Work persona as a choice question, equipment selection, work location details. AI selected a choice type for persona and a table lookup for location without being told either.
2. A best-practice suggestion fired on a short description too thin for a requester to understand. Accepting it rewrote both the short description and the description.
3. Conditional display. Hybrid shows office location, seat, and floor as mandatory. Remote hides those and shows the shipping question instead.
4. A nested condition. The employee address block appears only when work persona is remote and shipping required is yes.
5. The delivery date. The prompt described only the business rule, that a date less than four business days from submission should throw an inline error. It generated the question and the validation together. The validation was implemented as a client script.

That last step is the one to notice. David never specified a question type, a UI policy, or that scripting was needed. He described business logic. Authoring in Catalog Builder chose the metadata.

Two things confirmed inside Catalog Builder afterward: anything generated by AI carries an AI tag next to it, and the template's requester and manager questions survived generation intact rather than being overwritten.

Also new since Australia: a single UI policy can now carry one condition with multiple action variables. Previously the same outcome took three separate UI policies. This works whether built manually or with AI.

Best practices in Catalog Builder: a guardrail written in plain language

New to Australia, admins can define custom best practices for catalog item generation, written in plain language in a knowledge article. When a process owner submits a generation request, the model compares what they're building against those best practices and surfaces suggestions inline when something falls short.

The details:

• Pre-requisites: Install Otto for Catalog Generation and check that the catalog item creation skill is turned on.
• Out-of-box best practices come included, and admins can edit or overwrite them entirely.
• The most recently published version is always the one used for comparison.
• Enable suggestions via a property under Service Catalog Administration properties, in the catalog items section.
• Scope is anything the catalog item generation skill can create.

This is governance that scales without review meetings. Standards get enforced at the moment of authoring.

Step-based request fulfillment

Step-based fulfillment is not new, but our poll found most attendees had never heard of it. The poll also showed that for most teams, the platform team also builds fulfillment for business-related catalog items.

The idea is straightforward. Rather than linking a finished catalog item to a flow an admin built, the process owner defines the fulfillment inside Catalog Builder. Three step types ship out of the box, and custom steps are configurable if something else is needed, such as sending a notification.

Manager approval. Routes to the manager of whoever the request is for. Nothing to configure and no approver to pick. It reads the manager attribute and routes the request appropriately. 

Custom approval. Named users or groups, with conditions. We skipped this since it introduces complexity for process owners. 

Task creation. Short description, description, assignment group, assigned to, priority. One task per step.

Sequencing and quorum are both configurable per step: run after the previous step or alongside it, and require any member of a group to approve or all of them.

The point of handing this over is not that it's clever. It's that a desk move from one part of an office to another, needing one manager approval, has no business consuming platform team capacity. And when it does, the item usually just never gets built.

 

Step-based fulfillment limitations

Knowing the ceiling is what makes delegation credible rather than reckless. Step-based fulfillment isn't the right tool for:

• Approver routing driven by a decision table
• Wait-for-all parallel approvals across independent steps, which need subflow work
• A task description built from a variable answer
• Anything that calls another system, or carries external dependencies

Past that line, someone writes a custom fulfillment step or hands the item a real Flow Designer flow. That's an admin job, and it's a short, nameable list rather than an open-ended dependency.

Part 2 demo: David builds his own fulfillment and tests it

Four steps, built by David:

1. Manager approval, no condition. Always required.
2. Custom approval to the Workplace Services group, any member can approve, sequenced to run after the manager step.
3. Custom approval to IT Logistics, any member can approve, conditional on work persona being remote, since only remote requests involve shipping to a home address.
4. A task against the IT Logistics group with a short description and an assignee, created once approvals complete.

Then the full end-to-end test, still as David. Submit the request as a remote employee. The date validation fired correctly on a weekend date less than four business days out, and cleared on a valid one. The manager approval landed in the right queue and was approved. The request advanced to a Workplace Services approver, then on to IT Logistics.

One incidental detail worth keeping: while impersonating David, the users table wasn't visible when setting the task assignee, because David isn't an admin. The guardrails held during the demo as expected.

David built the item, built the fulfillment, and tested the whole path. He never filed a request and waited.

Questions worth repeating

Can users just type what they want instead of using a catalog item? That experience is AI Search and Virtual Agent, and it runs on the catalog items that already exist. Because facilities built a desk-move item, someone typing "I want to move my desk" gets routed into a conversational handoff rather than a form. The more catalog items exist, the richer that experience gets. Conversational self-service is a reason to build more items, not fewer.

Some teams prefer maintaining variables, variable sets, and UI policies directly in the instance. This is reasonable for complex cases. But pointing a process owner at the "maintain items" view will scare them off, which is precisely the gap Catalog Builder fills.

Does an admin still need to add a flow? Not for the simple items, if process owners are trained on step-based fulfillment. That's the whole point of handing it over.

Three things to do next

Reuse what works. Pick one group of questions the team rebuilds constantly, turn it into a question set, and attach it to the relevant template. Process owners get consistency without rebuilding forms, admins stop fielding one-off requests for the same four fields, and AI-generated items inherit the standard automatically.

Hand over fulfillment. Rebuild one low-risk item's fulfillment in steps and let the process owner drive it. Manager approval, group approvals, and task creation need no Flow Designer work. Building the form gets a team most of the way. Handing over fulfillment is what removes the platform team from the loop entirely.

Know where to step in. Write down the cases that come back to the platform team, decision table routing, wait-for-all approvals across steps, variable-driven task detail, anything integrated, and share that list on day one. When a finance team asks for concurrent multi-party approvals, everyone already knows where it goes. Guiding those cases beats owning the whole queue, and a clear handoff is what keeps the guide model from quietly reverting.

Gatekeeper to guide starts with one step: one owner, one item, one form.

Watch the recap below.

Explore upcoming Platform Academy sessions here: https://sn.works/academies