Platform Craft — perspectives and practical advice for the ServiceNow Platform
For most of the last decade, our job as platform builders has been to design destinations. We built portals, refined catalog forms, tuned Virtual Agent topics, and shaped the Employee Center into a place people would actually want to visit. The screen was the product. That era is quietly ending.
The IT world is moving toward headless architectures, where employees access company resources spanning multiple departments through one interface — or several — and get the same result no matter where they started. Ask a question in a chat window, speak it to a voice assistant, or type it into a search bar, and the answer should be identical. The entry point becomes a detail. The capability becomes the product.
This shift forces an uncomfortable but useful question: in a headless world, what is ServiceNow actually for?
As the AI workflow orchestration platform, ServiceNow can play one of three roles, and naming the role explicitly is the first design decision you should make.
It can be an entry point — the surface employees interact with directly, whether through Employee Center, Virtual Agent, or a future conversational layer. It can be a data and action repository — the system of record and the engine that executes work, fed by interfaces that live elsewhere, like Moveworks, a custom voice assistant, or Microsoft Copilot. Or it can be both, serving its own interfaces while also exposing its data and actions to anything else that asks.
Most mature platforms today are accidentally "both" without having decided to be. They support Employee Center, Virtual Agent, Moveworks, voice, and email all at once, each with its own configuration, its own content, and its own maintenance burden. That sprawl is exactly what headless design is meant to resolve — but only if we change how we approach the work.
The transition to headless is, at its core, a change of design focus. Instead of starting with "what should this screen look like," we go back to two fundamentals that every channel ultimately depends on: data and actions. Get these right once, and every channel — present and future — can consume them. Keep designing per-screen, and you will rebuild the same logic over and over for each new interface.
For any employee question, the first task is to identify the sources of data that can provide an answer. When that source is ServiceNow, two questions matter. Is the data ready for human consumption — clean, current, and phrased in language an employee understands rather than a schema only an admin could love? And can that data be reached by other systems through APIs or a query layer, so a third-party assistant could surface it without screen-scraping a portal?
When the answer lives outside ServiceNow, the question flips: where is it, and can ServiceNow reach it? This last point is the one teams skip, and it is the most important if you intend ServiceNow to be an entry point. An entry point that can only answer questions about its own records is a narrow door. If employees are going to ask ServiceNow about anything — HR policy, an order status, a building access request — then ServiceNow needs federated, governed access to data far beyond its own tables.
Actions follow the same logic, but the mental shift is sharper. For every action an employee can perform, define what information is required to complete it. This is where we move from form design to input definition.
A form answers "what fields go on this screen." An input definition answers a better question: what data does this action genuinely need, regardless of how it's collected? Then comes the part that makes headless feel effortless — how much of that data can we obtain without asking the user at all? Identity, location, department, recent activity, and entitlements are often already known. Every input we can resolve silently is one fewer question an employee has to answer, on any channel.
Two more dimensions complete the picture. Where does the action actually take place — in ServiceNow, or in a downstream system ServiceNow orchestrates? And how is it triggered — synchronously, through an event, through a flow? The key discipline for headless actions is a clear, stable definition of outputs. When an action's inputs and outputs are defined once and exposed cleanly, you stop forcing every channel to maintain its own configuration just to gather and pass data. That duplicated configuration is precisely the technical debt headless design exists to eliminate.
Headless doesn't mean we stop caring about experience. It means the experience is increasingly assembled at the edge, by whatever interface the employee chose, from capabilities we expose at the core. Our craft moves from pixels to contracts — well-defined data sources and well-defined actions that any channel can trust.
Decide what role ServiceNow plays. Inventory your data and your actions. Define them once, cleanly, and let the screens take care of themselves.
.svg){kind=icon}
