Virtual Agent API - Appointment booking - Calendar / Appointment Scheduler

KlNe · 3 weeks ago

Hi all,
I am trying to setup a bot to bot conversation using the Virtual Agent API. Its an asynchron conversation.
The VA Design is ready and works entirely perfect within ServiceNow Virtual Agent ecosystem.

When I hit the point in the conversation where the user gets a "calendar widget" to chose a free slot for the appointment booking like this

...the payload from ServiceNow VA API to the Lead Bot shows this as payload:

{
  "uiType":"OutputText",
  "hideControl":false,
  "value":"Sorry, this channel is not supported",
  "excludeFromUnreadCount":false,
  "shouldSkipTranslation":false,
  "shouldForceTranslation":false
}

I wonder if this is a limitation of the Virtual Agent API as it is designed primarily for Conversational purposes and cannot cope with such?

Vikram Reddy · 3 weeks ago

Hi @KlNe ,

This isn't a general limitation of the Virtual Agent API for conversation itself, it's specific to the calendar/slot picker step. The "Sorry, this channel is not supported" text is the platform's built-in fallback message, and it fires whenever a Virtual Agent Designer control isn't in the set of rich controls your receiving channel has declared support for.

Here's the mechanic. When you build a bot-to-bot integration over the Virtual Agent API, you're going through the Conversational Custom Chat Integration Framework (CCCIF), even if you never touch that name directly. CCCIF's whole job is to transform ServiceNow's "default rich controls" into a payload your external channel can render. Not every Designer control is in that default, mappable set. A Date/Time input control (which is what drives that calendar widget, and also what the Appointment Scheduler/Walk-up booking utility sits on top of) is a heavy, client-rendered widget built for the native Agent Chat widget or Now Mobile. It was never designed to be flattened into a generic async JSON payload for an arbitrary bot-to-bot channel, so when the conversation hits that step, the platform can't produce a renderable representation for your channel and drops back to the "not supported" text instead of the widget payload.

Check this before you spend time elsewhere:

Open the topic in Conversation Designer and confirm exactly which control that step uses. If it's the native calendar/appointment scheduling widget (common in CSM/HR walk-up flows), that's almost certainly the cause.
Look at your channel's control mapping (the "map rich controls to the channel" step of your CCCIF/custom channel setup). By default a generic REST-based channel typically only gets OutputText, Picture, and Picker/Choice-style controls mapped, not Date/Time.
As a sanity check, run the same topic through a channel that has more native support (the standard web widget, or Slack/Teams if configured) and confirm the calendar renders fine there. That isolates the issue to the channel/control boundary rather than your topic logic.

For the fix, I wouldn't try to force the native calendar through the API. Two realistic paths:

Redesign that step to use a control that's actually part of the default, mappable rich control set, for example a Dynamic Choice or Picker control that you populate via script with the available appointment slots as plain strings/buttons. This keeps the flow entirely conversational and avoids the widget dependency altogether, which tends to work better for bot-to-bot/async integrations anyway.
If you need to keep the true calendar experience, you'll have to handle that uiType yourself on the Lead Bot side and render your own date/time picker there, per how custom controls work in CCCIF, and post the selected date/time back in the format the Date/Time control expects.

Some background reading that lines up with what you're seeing:

Thank you,
Vikram Karety
Octigo Solutions INC