ServiceNow Virtual Agent Topic Explained

What Is a Virtual Agent Topic?

A Virtual Agent topic in ServiceNow is a self-service automation that guides conversations between a user and a chatbot to fulfill a specific task. A topic might handle password resets, provide status updates on pending requests, help users reset hardware, or walk through troubleshooting steps. Each topic is a directed workflow: it asks questions, captures information, performs actions, and reports results back to the user.

Topics live in the Virtual Agent Designer, which is a visual, low-code environment for designing conversation flows. You define the conversation blocks, decision logic, and integrations without writing code. When a user interacts with the Virtual Agent and asks something the topic covers, the Virtual Agent routes to that topic and guides the conversation through the defined flow.

How Topics Guide Conversations

A topic consists of blocks that represent conversation elements. A message block displays text to the user. A question block asks for input and branches based on the answer. A script block performs logic or calls external systems. A form block collects structured information from the user. A topic flows through these blocks sequentially, creating a guided experience.

Topics often use conditional logic to personalise the conversation. If a user answers “yes” to a question, the topic follows one path; if “no”, it follows another. If a user provides information that matches an existing request or ticket, the topic might retrieve that data and ask for confirmation rather than starting from scratch.

Common Virtual Agent Topics

Password reset is a classic topic: the user confirms their identity, the system resets their password, and sends them a temporary credential or a reset link. Track my request is another: the user provides a request number, the topic looks up the request, and displays its status. Incident report helps users log incidents by asking what the problem is, what device is affected, and when it happened, then creates an incident with that information.

Troubleshooting topics walk users through diagnostic steps: “Is your internet connection working? Yes, then let’s check DNS. Can you access our intranet? No, then your browser might have a proxy issue.” Each answer narrows down the problem and can point to a solution or escalate to human support if automated resolution is not possible.

Integration with Service Management Modules

Topics integrate with underlying ServiceNow tables. A topic might query the incident table to find open incidents assigned to the user. It might create a new incident, request, or change based on conversation inputs. It might query knowledge articles to find relevant self-service solutions and present them to the user before escalating to support.

Topics also integrate with authentication and identity systems. They know who the user is, so they can personalise the experience and access only data relevant to that user. This prevents users from seeing other people’s requests or personal information.

Topic Discovery and Routing

When a user begins a conversation with the Virtual Agent, how does the system know which topic to use? The Virtual Agent uses topic discovery: it analyzes what the user says and matches it to the topic that best fits their need. Topics are tagged with keywords or phrases that help with matching. If discovery works well, users get routed to the correct topic immediately. If discovery fails, users see a menu of available topics and select the right one.

Topics can also escalate to human support. If a topic cannot resolve the issue automatically—perhaps the user asks a question the topic does not handle—the topic can transfer the conversation to a human support agent with full context already captured.

Common Misunderstandings

Topics are not just chatbots that answer questions. They are automation flows that perform actions: create tickets, look up information, apply business rules. A topic might ask a question, but its value comes from the action it takes based on the answer. A topic that only answers questions without performing actions does not use Virtual Agent fully.

Topics are also not static. After you deploy a topic, you monitor how users interact with it. If users frequently branch to the “other” option or escalate to support, the topic might not be addressing real user needs. Iterate on topics based on usage data to improve their effectiveness.

Topic Development Considerations

Topics require testing before deployment. Does the conversation flow make sense to real users? Do questions produce the intended answers? Does the topic handle edge cases—users who answer unexpectedly or provide invalid data? A topic that breaks or loops is worse than no topic at all.

Choosing which conversation to build first

The first topic is often picked by whoever complains loudest, and that is how a conversational service ends up with a polished password flow and no working path for the requests that actually flood the queue. A better filter asks three things about each candidate conversation: how often it happens, whether the answer lives in a record the platform already holds, and what the bot is allowed to change once it has an answer. A topic that only reads data is cheap to build and easy to reverse. A topic that writes to a request, resets an account or grants access carries identity and approval risk that a reading topic never does. For a service owner, the decision is not which topic is impressive but which one can be verified, measured and switched off without harming anyone.

Candidate conversation	Data it depends on	What the topic may change	Main risk	Suggested order
Status of a request the user already raised	Requests tied to the signed-in user only	Nothing; read and explain	Showing another person’s record if scoping is loose	Early
Password reset for a locked account	Identity check and account lock state	Reset initiation through the identity process	Reset issued to an unverified person	Early, after identity is proven
Hardware troubleshooting steps	Knowledge articles for each device family	Nothing; guides the user through steps	Steps out of date after a model change	Middle
New access request	Catalog item and approval rules	Creates a request that goes through approval	Requests for the wrong entitlement	Later, once catalog is clean
General policy question	Knowledge search	Nothing	A topic duplicates what search already answers	Often not a topic at all

Designing the handoff before the happy path

Many topic designs spend their effort on the path where the user says yes, provides the right detail and gets an answer. The path that decides whether users trust the bot is the one where the conversation stops working. A human agent who receives a transfer needs the identified user, the question as the user phrased it, what the topic already tried and what it could not verify. Without that, the transfer simply moves the frustration to a second desk. Designing the exit first also reveals which questions the topic cannot answer honestly, which is often the signal that the topic should be narrower.

1. Write the single question the topic must answer and the one fact in a record that proves the answer.
2. List every table, record and integration the topic reads, and confirm the signed-in user is scoped to their own rows.
3. Decide whether any block writes data. For each write, name who approves it and what the user sees if the write fails.
4. Define the exit ramps: an explicit “talk to a person” choice, an automatic transfer after repeated misunderstanding, and a fallback message when a dependency is down.
5. Pass the transfer context to the receiving team and check it appears on the case or task the agent actually opens.
6. Test with phrasings from real tickets, not with the words the designer expects.

Why a topic never fires, and how to find out

When a topic is built and published but users never reach it, the cause is usually upstream of the conversation design. Discovery depends on the words a user types, so a topic named for an internal product code will miss the phrase people actually use. Two topics with overlapping keywords compete, and the one that wins may be the less useful one. Channels can also be off: a topic enabled on the portal may not be available in the chat widget a team embedded later. Start by reading the conversations users had that ended in a menu or a transfer, because those show the phrases discovery did not match.

• Keywords written for the internal name of a service instead of the words users type
• Two topics claiming the same phrase, with no priority rule agreed between them
• The topic published on one channel but not the one users arrive through
• Identity not present in the session, so the topic shows a login prompt the user does not understand
• A language setting that routes non-default language users to nothing

Keeping topics accurate after go-live

A topic is a claim about how a process works, and processes change. A new hardware standard retires the steps a troubleshooting topic walks through. A renamed assignment group breaks the transfer. A common failure is that a topic fails quietly: it keeps running, gives an answer that was true last year and produces transfers that nobody reads. Assign an owner for each live topic, review the transcripts where users left the flow, and tie each topic to the knowledge articles it relies on so that when an article changes, the topic owner is told. Retire topics on purpose. A topic with no traffic is either solving a problem nobody has or sitting behind a discovery failure, and both need a decision.

When a conversational topic is the wrong tool

A topic adds value when the answer is a short, repeatable sequence that a person would otherwise have to walk a user through. It adds little when the user needs judgment, when the situation changes the answer every time, or when the bot cannot confirm who is asking. Destructive actions, exceptions to policy and anything touching money or privileged access belong to a person or to an approval workflow, with the conversation serving only as the intake. Recognizing these cases early saves expensive rework, because a topic that promised too much has to be taken apart in front of users.

Can one topic serve two departments?

It can, but only if both departments agree on the answer and the transfer destination. When their policies differ, split the topic at the first question that separates the two groups, so each branch has a single owner and a single set of steps.

Does building a topic need a developer?

The design work is mostly configuration and content. A developer is needed when a block calls an external system, performs a custom lookup or writes to a record in a non-standard way. Keep those blocks few, documented and owned, because they are the parts that break after upgrades.

What should a transcript review look for?

Look for the last message before a user left, the phrase that failed discovery, and any answer the user rejected or corrected. Repeated corrections on the same step point to a wrong instruction. Repeated exits on the same question point to a missing topic or a discovery gap.

How is a topic different from a catalog item?

A catalog item is a form that produces a request with a fixed structure. A topic is a conversation that may end in a read, a request, or a transfer, depending on what the user says. Many good designs use a topic to collect the details and then hand off to a catalog item, so the structured record is still created the same way every time.

A list of real requests from the last few months is a useful input for deciding which conversations to build, so start there and score each one against the criteria above. For handoff design, the escalation handoff post is a useful companion, and the self-service service page covers the wider scope.

How a Virtual Agent topic should handle a system outage

When users ask about an outage, the topic should check whether the platform already holds an active major incident or service-impacting record for the service they name, tell them its current status, and stop them from raising a new incident for the same fault. The aim is to answer the question the user really has, which is whether the problem is known and when to expect news, and to keep duplicate tickets away from the people fixing it.

In most implementations the conversation works best in five moves.

Move	What the topic does	What to watch for
Recognise	Matches phrases such as “is the VPN down” or “nobody can log in” to an outage topic	Users rarely say “outage”; include the words they actually use for each service
Check	Looks up open major incidents or known service impacts for the service the user named	The lookup should read only status and public wording, never internal work notes
Inform	Shows the current status and the last update time in plain words	A stale message is worse than none, so the topic should say when it was last updated
Offer	Gives a workaround from knowledge, or offers to notify the user when service returns	Only offer a workaround that support has approved for this fault
Hand off	If nothing is known, creates one incident with the service, symptoms and time captured	Ask which service and where the user is working before creating anything

The check step is the one most designs skip. Without it the bot treats every outage report as a fresh incident, the queue fills with duplicates, and the service desk spends the first hour of the outage merging them instead of working the fault.

If the answer is unknown, the transfer to a person matters as much as the answer itself; the guide to Virtual Agent escalation and hand-off sets out what a human agent needs to receive. How the underlying records are managed is covered in ServiceNow major incident management, and teams that want an existing bot reviewed for gaps like this can start from Virtual Agent optimisation.

Should the topic explain the cause of an outage?

Usually not. Until the cause is confirmed, the topic should repeat only the wording that the incident owner has approved for users, because an early guess that turns out wrong damages trust more than a short “we are investigating.”