Multiple virtual agents on one portal based on user
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi everyone,
has someone been able to configure virtual agent for a portal in a way that let's only a part of the users use Now Assist and the other part use "normal" virtual agent?
I read that OOTB only one assistant can be added to a portal, so I don't think it can be done configuration-based, but I would be happy to be wrong. I'm not an expert in virtual agent so I'll probably be wrong but is there another way, like for example having a "normal" agent that in some cases, if the user is enabled, can call another agent that uses now assist?
Please let me know if there is some way to do this, even custom, just for evaluation because I would rather not customize the assistants or the portal.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hey @Al_Andrea,
I'm assuming a fairly standard setup here: one Service Portal (or Employee Center), the stock Agent Chat widget, not a fully custom front end. For that case, here's the honest answer.
You're right that OOTB there isn't a "different assistant for different users" toggle. An Assistant in Conversational Interfaces gets tied to a portal through its Display experience setting, and that's effectively a one-to-one binding, whichever Assistant you point at Employee Center becomes the default virtual assistant for everyone hitting that portal. There's no role or group condition on that screen.
That said, it's not a dead end, and your instinct about "one bot deciding to hand off to another" is closer to how people actually solve this than you'd think, it's just not bot-to-bot, it's script-to-branding-key. ServiceNow exposes a launch endpoint, sn-va-web-client-app.do, that accepts sysparm_branding_key (the branding key of whichever bot/assistant you want to open, found under Conversational Interface > Settings > General > Branding) and sysparm_default_topic (a sys_id from sys_cs_topic). You can fire that from any button, link, or client script. Pair that with a small server-script check on the chat launcher widget, gs.hasRole(), a group check, whatever, and you get exactly what you described: the launcher itself decides at render time whether a user gets the Now Assist branded bot or the classic VA branded bot, all on the same portal, no second portal and no modification to either assistant's actual topics.
One thing to watch: there is a Roles field on the Service Portal > Agent Chat > Configuration record itself, and there's at least one open community thread reporting that field doesn't reliably restrict access the way you'd expect. Don't lean on that field alone, do the gating in your own script logic instead.
Also worth flagging since you said "just for evaluation": Now Assist skills draw on a separate entitlement per user, so even a scripted split like this only matters if the underlying licensing actually differentiates your two user populations.
Thank you,
Vikram Karety
Octigo Solutions INC