Virtual Agent Topic Not Ending After Static Choice Selection in CSM Portal (Zurich 11M)

[ShamshadB284239]

Hi Team,

I'm facing an issue with ServiceNow Virtual Agent (Zurich Patch 11M) in the CSM Portal.

Behavior observed:

• I have a Static Choice node with an option like "I'm Done".
• When the user selects the choice, the flow correctly traverses to the next node.
• Debug logs show that the choice value is sometimes coming as empty, null, or undefined.
• Despite the empty value, Virtual Agent still follows the correct path based on the selected option.
• However, the conversation does not end. The topic remains active and the interaction stays open.

Additional observations:

• The same configuration appears to work differently in the VA Test Panel.
• The issue is primarily occurring in the CSM Portal.
• Since the flow is able to transition to the next state, it seems the choice selection is being recognized internally, but the conversation termination is failing.

Question: Has anyone experienced a similar issue where Static Choice values are empty/undefined but the flow still navigates correctly, while the conversation fails to close? Are there any known fixes, workarounds, or Zurich 11M limitations related to ending a Virtual Agent topic from a Static Choice selection?

[musislam]

Hi,

I've seen a similar pattern before where the Test Panel behaves fine but the portal keeps the conversation open. Couple of things to narrow it down:

1. Looking at your diagram, the "I am done" edge seems to route around the Decision node rather than into an explicit End node. If the branch loops back or just stops without a Topic End / End node, VA in the web client keeps the topic active even though the flow looks finished. Can you confirm what the last node on that path actually is?

2. How are you reading the static choice value - through the Decision node's built-in condition on the choice, or via a Script Decision using vaInputs.<node_name>? The empty / undefined you see in the debug logs is usually the choice being evaluated before the input is committed, which also explains why it still branches correctly.

3. Is this the OOB Customer Service Portal with the standard sn-va-web-client widget, or an embedded / custom widget? And was the topic built by hand or generated via the Zurich Setup Topic wizard?

If you can share those I'll rebuild the topic on a Zurich instance and post back a screenshot of a flow that closes properly.

[ShamshadB284239]

Thanks for looking into this, Macki.

1. The "I'm Done" option currently routes to a response node that displays a closing message and then reaches the end of the flow. There is no loopback in this path. However, even after reaching the final node, the conversation remains active in the CSM Portal and the interaction is not getting closed.

2. I am not using a Script Decision to evaluate the selection. The branching is based on the Static Choice node's built-in choice paths. What's interesting is that although the value sometimes appears as empty, undefined, null, or {} in logs/debugging, the flow still follows the correct branch when "I'm Done" is selected. Because of that, it seems the platform is recognizing the choice internally, but something is preventing the topic from terminating properly.

3. This is occurring in the CSM Portal on a Zurich Patch 11M instance. The same topic behaves differently in the VA Test Panel. The topic was built manually rather than generated through the Zurich Setup Topic wizard.

Additional observation: The issue seems specific to ending the conversation.but when the user selects "I'm Done",/or any other way where it is leading to the end the topic remains active and the interaction does not close. For other topics in the same environment, interaction closure is working as expected.

Thanks for your help.

[musislam]

Hi Shamshad,

Thanks, that narrows it down. I think your flow is fine and the topic is genuinely ending. What you are hitting is that ending a topic and closing the interaction are two different events in Virtual Agent.

When the last node of a topic runs, control goes back to the conversation, not out the door. The conversation stays open so the user can ask something else, and the interaction sits in Work in Progress. Nothing inside a topic, including a closing Text response, closes it.

I ran it on my instance to be sure. Mine is on Australia, one release ahead of your Zurich Patch 11M, but this part has not changed. I opened the VA web client, had a normal exchange and left it: interaction IMSG0000002 sat at State = Work in Progress, which is your exact symptom. I then clicked End conversation - Yes in the client, and the same record moved to Closed Complete a minute later. Nothing else changed.

So the interaction closes on one of two events, and neither of them is "the topic finished".

First, an explicit end: the End conversation control in the web client, or one of the commands in sys_cs_contextual_action (Bye = bye, Restart = restart). You can add synonyms to the Commands field on those records, comma separated, though you cannot create new records in that table.

Second, the hourly scheduled job Time Out Abandoned VA Conversations, which runs sn_cs.VASystemObject.faultAbandonedConversations(). It faults conversations idle for longer than com.glide.cs.conversation_idle_timeout, which is 7200 seconds out of the box. Worst case, the interaction sits open for two hours plus the job's next run.

That also explains the Test Panel difference. The panel is its own channel record with its own Conversation Idle Timeout (3,600 on mine, in sys_cs_channel), and closing or restarting the panel tears the session down, so you never see the interaction linger.

On the empty, null or undefined choice value, I would stop chasing it. A Static Choice branch is resolved on the choice node's own outbound path, not by reading the variable back, which is exactly why the branch is correct while the variable looks empty in debug. It has nothing to do with the closure.

For your "I'm Done" path, set Conversation Idle Timeout on the channel record your CSM Portal uses rather than the global property, so only that channel closes quickly. The hourly job is the floor on how fast it can close. If you need it closed the moment the user picks "I'm Done", the supported hook is the end conversation command, not the topic, so either point the closing message at the End conversation control, or add your wording to the Bye contextual action.

One caveat from my test: typing bye fell through to the fallback topic on my instance rather than firing the Bye command, so check that record behaves on yours before you lean on it. The UI control closed it every time.

If that gets you there, mind marking it as the recommended solution? Helps me support these better for the community.

Macki | Deloitte AU | Engineer Lead

[ShamshadB284239]

Hi,

Thank you for the detailed explanation. That does align with what I have observed during my testing.

I added a closing message in the end node of the topic, and the topic executes successfully until the end without any issues. It does not appear to be stopping or failing anywhere in the flow. The only behavior I am seeing is that the interaction remains in Work in Progress and does not close immediately.

I also verified the same behavior with other topics in the instance, and they behave similarly. Based on this, I believe the topic is ending correctly and that this is the platform's expected out-of-box behavior.

Could you please confirm whether it is expected for interactions to remain open and eventually move to a closed/abandoned state through the timeout process, rather than being closed immediately when a topic ends?

Thanks for your help.

Regards,
Shamshad Begum