Genesys Cloud - Main

I am setting up Genesys CX integration using Unauthenticated and Authenticasted Web Messaging and BYOT/Dialogflow CX.

After reading through the documentation, I am not clear on a few points and was hoping for some clarification.

1. Based on the the way the documentation reads, it sounds like web messaging authentication is a binary un-authenticated or authenticate state. From within the messenger bot itself, you cannot transition from on state to another, is that correct? Something like the image below where you start off unauthenticated and then transition to authenticated. The use case would be where the bot can provide a certain level of assistance to non-authenticated users but if the user wants specific details of their account, they would need to authenticate and could then continue with the bot and have access to more capabilities.

2. If the above is true, and it is either all un-authenticated or all authenticated, is the architectural approach to have to two messenger deployments, one to handle authenticated users and one to handle non-authenticated users and what would the suggested approach be to render the specific messenger deployment?

3. If the user is authenticated to the customer website, do they also have to authenticate independently to Genesys web messaging, so two different authentications?

Thank you for pointing us to the optimal design approach.

---

Documentation I Referenced

Genesys Web Messaging Authentication

Get started with authenticated web messaging

Authenticated web messaging attributes

Enable authenticated web messaging

#ConversationalAI(Bots,AgentAssist,etc.)

------------------------------
Alan Klein
Cresta
------------------------------

Yes, you have found the unfortunate problem with web messaging - it is either all or nothing when it comes to authentication.  Unfortunately, I have gotten nowhere getting the PM to understand the need for step-up authentication.  I would suggest you vote on the idea and send messages to him regarding this.  Web Messaging - Step-Up Authentication | Genesys Cloud Ideas Portal (aha.io).  I find without this, there is a big issue deploying Web Messaging.

------------------------------
Robert Wakefield-Carl
Avtex Solutions, LLC
Contact Center Innovation Architect
https://www.Avtex.com
https://RobertWC.Blogspot.com
------------------------------

We have a similar situation for several of our product lines, and to get around this we:

Provide a single up-front bot and messenger deployment. This handles all of the un-gated content as well as a path in the bot to authenticate. Similar to your screenshot, we ask the visitor for their email or phone number, then within the bot we do a data action (API call) to Salesforce or other platforms. If we find this email or phone, we ask the visitor to validate something about their account (like a PIN), and if successful we transfer them from one bot to another bot flow - and this second bot flow is not tied to a messenger deployment, you can only get there after getting through the gate of the first bot. This second bot has the same general and ungated knowledge, and all of the private info linked to the logged in user.

The way I've understood Authenticated messaging from the Genesys design, is that you're supposed to stash it behind a website login - IE someone logs into their account on your website, and then they access authenticated messaging deployment. Their take is a very niche and specific setup, that does not seem to work for many of us in the user base.

------------------------------
Brad Murlin
Zillow, Inc.
------------------------------

Hi Brad,

How do you get around the security around them entering a PIN on a bot? Slot's can't be marked as secure content, and all slots are automatically marked as outputs?

------------------------------
Anton Vroon
------------------------------

Original Message:
Sent: 12-28-2022 14:21
From: Brad Murlin
Subject: Authenticated Web Messaging - Better Understanding the Capabilities / Design Guidance

We have a similar situation for several of our product lines, and to get around this we:

Provide a single up-front bot and messenger deployment. This handles all of the un-gated content as well as a path in the bot to authenticate. Similar to your screenshot, we ask the visitor for their email or phone number, then within the bot we do a data action (API call) to Salesforce or other platforms. If we find this email or phone, we ask the visitor to validate something about their account (like a PIN), and if successful we transfer them from one bot to another bot flow - and this second bot flow is not tied to a messenger deployment, you can only get there after getting through the gate of the first bot. This second bot has the same general and ungated knowledge, and all of the private info linked to the logged in user.

The way I've understood Authenticated messaging from the Genesys design, is that you're supposed to stash it behind a website login - IE someone logs into their account on your website, and then they access authenticated messaging deployment. Their take is a very niche and specific setup, that does not seem to work for many of us in the user base.

------------------------------
Brad Murlin
Zillow, Inc.
------------------------------

Variables marked as output, whether a slot or custom variable, just means that the data in that variable is available to be passed back down to the inbound flow that triggered the bot. Any variable that is passed over to the inbound flow is still basically private data.

Unless you specifically store the value into Participant Data or an External tag, the value can only be seen:

• by someone reading the chat transcript in the admin UI as a supervisor/admin
• by someone digging through the utterance history in the bot flow
• by someone with API access who pulls down the 'recording' aka transcript of the conversation
• by Genesys care staff if given permission on an open case to look at this conversation transcript

All of those access scenarios can be enforced with some sort of permission, and in our case the security info we validate with is NOT the last 4 of an SSN or a birth date etc. so the risk is minimal considering the same staff with the Genesys access can view this info in Salesforce and other systems.

I seem to recall seeing something about secure flows for bots coming soon :tm: but cannot find anything on the forum or ideas board to support this.

If the above situations are deemed too risk to use, you could do something slightly dirty like forward the conversation from bot A to bot B just for validation and back to A, and slap bot B into it's own division that mostly no one has access to.

------------------------------
Brad Murlin
Zillow, Inc.
------------------------------

Original Message:
Sent: 12-28-2022 19:11
From: Anton Vroon
Subject: Authenticated Web Messaging - Better Understanding the Capabilities / Design Guidance

Hi Brad,

How do you get around the security around them entering a PIN on a bot? Slot's can't be marked as secure content, and all slots are automatically marked as outputs?

------------------------------
Anton Vroon
------------------------------


Original Message:
Sent: 12-28-2022 14:21
From: Brad Murlin
Subject: Authenticated Web Messaging - Better Understanding the Capabilities / Design Guidance

We have a similar situation for several of our product lines, and to get around this we:

Provide a single up-front bot and messenger deployment. This handles all of the un-gated content as well as a path in the bot to authenticate. Similar to your screenshot, we ask the visitor for their email or phone number, then within the bot we do a data action (API call) to Salesforce or other platforms. If we find this email or phone, we ask the visitor to validate something about their account (like a PIN), and if successful we transfer them from one bot to another bot flow - and this second bot flow is not tied to a messenger deployment, you can only get there after getting through the gate of the first bot. This second bot has the same general and ungated knowledge, and all of the private info linked to the logged in user.

The way I've understood Authenticated messaging from the Genesys design, is that you're supposed to stash it behind a website login - IE someone logs into their account on your website, and then they access authenticated messaging deployment. Their take is a very niche and specific setup, that does not seem to work for many of us in the user base.

------------------------------
Brad Murlin
Zillow, Inc.

Thanks Brad.

For us, the issue is that for authentication our preferred method across channels is for the customer to use a PIN, like any password no one else should know what it is. 

For secure bot flow the stuff they have done so far that I'm aware of is that you can mark variables as secure content, and you can use secure data actions. However you can't mark any Slots as secure content, because no variable can be both an output and secure content and all slots are outputs. Apparently they didn't have a use case for using Secure Content for Slots or for such a thing as authentication within a bot when developing that, and more around retrieving secure information from a CRM like Salesforce and using it withing a bot. We have a specific use case for Authentication while In Q for voice with a bot, which we can't do securely currently because that is missing.
So we logged an Idea for Secure Bot flow slots https://genesyscloud.ideas.aha.io/ideas/DXVBOTS-I-34

------------------------------
Anton Vroon
------------------------------

Original Message:
Sent: 12-28-2022 21:09
From: Brad Murlin
Subject: Authenticated Web Messaging - Better Understanding the Capabilities / Design Guidance

Variables marked as output, whether a slot or custom variable, just means that the data in that variable is available to be passed back down to the inbound flow that triggered the bot. Any variable that is passed over to the inbound flow is still basically private data.

Unless you specifically store the value into Participant Data or an External tag, the value can only be seen:

• by someone reading the chat transcript in the admin UI as a supervisor/admin
• by someone digging through the utterance history in the bot flow
• by someone with API access who pulls down the 'recording' aka transcript of the conversation
• by Genesys care staff if given permission on an open case to look at this conversation transcript

All of those access scenarios can be enforced with some sort of permission, and in our case the security info we validate with is NOT the last 4 of an SSN or a birth date etc. so the risk is minimal considering the same staff with the Genesys access can view this info in Salesforce and other systems.

I seem to recall seeing something about secure flows for bots coming soon :tm: but cannot find anything on the forum or ideas board to support this.

If the above situations are deemed too risk to use, you could do something slightly dirty like forward the conversation from bot A to bot B just for validation and back to A, and slap bot B into it's own division that mostly no one has access to.

------------------------------
Brad Murlin
Zillow, Inc.
------------------------------


Original Message:
Sent: 12-28-2022 19:11
From: Anton Vroon
Subject: Authenticated Web Messaging - Better Understanding the Capabilities / Design Guidance

Hi Brad,

How do you get around the security around them entering a PIN on a bot? Slot's can't be marked as secure content, and all slots are automatically marked as outputs?

------------------------------
Anton Vroon


Original Message:
Sent: 12-28-2022 14:21
From: Brad Murlin
Subject: Authenticated Web Messaging - Better Understanding the Capabilities / Design Guidance

We have a similar situation for several of our product lines, and to get around this we:

Provide a single up-front bot and messenger deployment. This handles all of the un-gated content as well as a path in the bot to authenticate. Similar to your screenshot, we ask the visitor for their email or phone number, then within the bot we do a data action (API call) to Salesforce or other platforms. If we find this email or phone, we ask the visitor to validate something about their account (like a PIN), and if successful we transfer them from one bot to another bot flow - and this second bot flow is not tied to a messenger deployment, you can only get there after getting through the gate of the first bot. This second bot has the same general and ungated knowledge, and all of the private info linked to the logged in user.

The way I've understood Authenticated messaging from the Genesys design, is that you're supposed to stash it behind a website login - IE someone logs into their account on your website, and then they access authenticated messaging deployment. Their take is a very niche and specific setup, that does not seem to work for many of us in the user base.

------------------------------
Brad Murlin
Zillow, Inc.