Does anybody do fallbacks within custom topics?

[JaeggerLegane]

Hello all,

I was hoping to get some advice / learning on how other developers here have handled fallbacks.

Our situation:
- We have a general fallback topic which provides a live agent option + create incident
- We have dedicated topics for hardware, software, etc.

What we want:
- If a user is stuck in a dedicated topic, it should provide a fallback option
- We were thinking of using a static choice input where users can choose for "Something else" which then calls the fallback topic block

Some questions:
1. Does anybody here do something similar or do you all only work with the general fallback topic?
2. What do you do in situations where a user is in a topic and there is no relevant suboption in that topic?
3. For those with a fallback within every topic, how are you passing information from the parent topic to the fallback topic block? (so that record producers can dynamically update incident fields depending on the topic)

Thanks in advance!

[vaishali231]

hey @JaeggerLegane 

This is a very common design scenario when working with ServiceNow Virtual Agent, and your approach is definitely heading in the right direction.

1. General vs Topic-level fallback
In practice, most implementations use both:

A global fallback topic for unmatched intents

In-topic fallback options for when users are stuck mid-conversation

Using only a global fallback can feel too generic, so adding contextual fallbacks within topics helps improve the user experience.

2. Handling no relevant option within a topic
A common pattern is to include options like:

“Something else” / “None of the above”

“Talk to an agent”

“Create a ticket”

This ensures users always have a clear exit path and avoids dead-end conversations. Your idea of using a static choice to route to fallback is widely used.

3. Passing data from topic to fallback
To retain context:

Store values using VA/context variables (e.g., category, subcategory)

Call the fallback topic and reuse those variables

Use them in the fallback flow or record producer to populate fields dynamically

For better scalability, some implementations store a structured object (e.g., context details) instead of individual variables, so the same fallback can be reused across multiple topics.

4. Additional consideration
Before routing to fallback, some implementations allow a quick re-try (e.g., asking the user to rephrase the issue) to improve intent recognition, and only then redirect if needed.
*************************************************************************************************************************************

If this response helps, please mark it as Accept as Solution and Helpful.
Doing so helps others in the community and encourages me to keep contributing.
Regards
Vaishali Singh