Skip to main content

Automatically Associating Unauthenticated Visitors

  • Chat

Updated ~ minute read

Introduction

The Authenticated visitor flow (Dynamics Portals and Other Portals) has the main benefit that Live Assist for Dynamics 365 will automatically associate the Chat Activity to the contact record in Dynamics 365 allowing the the agent one click access to the contact record when they receive the chat. This requires the visitor to have an account and be able to log in to the portal.

The Unauthenticated visitor flow is unable to do this because Live Assist for Dynamics 365 can not identify the correct Contact record to associate to and the agent has to do this manually. The agent may do this manually by simply identifying a user based on their name and email address or have some other data that is considered unique enough to perform the association. This could be provided in the pre-chat survey or requested as part of the chat conversation by the agent.

So how can you take advantage of the authenticated flow but at the same time not require the user to be logged in to your website or portal?

This article will describe how.

To be or not to be Authenticated

What does it mean to be authenticated? A user on a portal that logs in with their username and password is considered authenticated. A user that is just on the website and has not provided any unique information about themselves is not. When that 2nd user wants to start a chat, what can be done to get information from them so that we can authenticate them enough for our purposes?

This is up to you. You decide what the minimum level of identification is that you require. In this article, we will assume that you are happy enough to identify a user simply based on their email address, but of course you can tailor this to your exact specification.

So we have identified the level of information required to authorise the user - the email address - but how exactly do we get hold of this?

To Pre-chat or not to Pre-chat

The standard solution to this is to use a pre-chat survey and ask them to provide their email address along with other information. The agent can then use this pre-chat survey data to search for the contact record, but this is a manual process. Unfortunately, the way that Dynamics works and the timings of events means that it is not practical to configure a work flow or plugin to inspect the pre-chat survey and update the Dynamics records before the chat is delivered to the agent.

Instead, this data needs to be captured after the chat has been requested, but before the chat is actually initiated. We need to insert ourselves into the flow and convert an unauthenticated visitor into one that is authenticated enough for our purposes.

The Flow

The article Authenticated Visitors (Non-MS Portals) details the standard flow for authenticated chats. That article however assumes that your user is going to be authenticated before they start the chat.

In our case, we are going to authenticate the user enough for our purposes during the chat flow, not before.

Automatically_Associating_Unauthenticated_Visitors.png

Steps

1-3: The visitor accesses the web page in their browser.

4 & 5: The visitor initiates chat by clicking on the chat button

6: Live Assist calls the configured JavaScript method that the webpage provides in order to be given the Encrypted JWT. This is where the standard path differs as we now need to get the authentication data from the user

7 & 8: The browser application requests the user to provide their identifying data. In this example, we are just asking for an email address. How the browser does this is up to the underlying web application, but an example could be to present an overlay box asking the user for the information.

9: The browser application passes the identification data to the Web App server and requests an encrypted JWT to be provided. It is important to perform this task on the server so that no public keys or data is held in the client's browser

10 - 12: The Web App looks up the user in Dynamics 365 using the Dynamics 365 Web API and extracts the GUID from the response. This GUID is then encrypted in a JWT which is passed back to the browser application.

13 - 15: The Browser Application passes the encrypted JWT to Live Assist which decrypts it and extracts the Dynamics GUID. This is then passed to the Dynamics instance.

16 & 17: The Agent now accepts the chat and Dynamics associates the Chat Transcript to the contact record specified by the GUID and pops the contact record automatically for the Agent.

With this flow you can still include a pre-chat survey if required to capture other information, such as what they wanted to talk about!

The Javascript

The example JS code provided in the article Authenticated Visitors (Non-MS Portals) assumes the user is already authenticated. To authenticate the user mid flow, we need to change the code a bit to asynchronously request the email address from the visitor, request the JWT from the Web App and then pass the result back to Live Assist.

Here is an example of how this could work (note this assumes that the functions for requesting the email data and for getting the JWT from the web app already exist:

function authoriseChatWithCallback(liveAssistAuthChatCallback) 
{
   //display form to get user email address
   getUserEmail((email)=> {

      //pass email address to Web App and get encrypted JWT back
      getJWT(email, (jwt)=> {

         //pass the jwt to Live Assist
         liveAssistAuthChatCallback(jwt);
      });
   });    
};

 

The Web App

How you build your web app is up to you. You could use a Web App or API App in Azure. You could also follow Nicholas Hayduk's article on companion apps for Dynamics 365 which also includes an interesting way of using a Dynamics' Plugin to achieve server side functionality.

Whatever mechanism you use, your app will need to achieve two main goals:

  1. Retrieve the GUID of the contact record
  2. Encode the GUID in an Encrypted JWT

To retrieve the GUID, you can use the Dynamics 365 Web API, with a query string that would look something like this:

https://DYNAMICS_URL/api/data/v9.0/contacts?
    $filter=emailaddress1 eq EMAIL_ADDRESS
    &$select=contactid

which would return a response looking something like this:

{  
   "@odata.context":"https://DYNAMICS_URL/api/data/v9.0/$metadata#contacts(contactid)",
   "value":[  
      {  
         "@odata.etag":"W/\"2162962\"",
         "contactid":"a9410148-610f-e911-a987-002248008742"
      }
   ]
}

You can now extract the contactid value and create the JWT. How to create and encrypt the GUID is described in Authenticated Visitors (Non-MS Portals). This is the value that is then passed back to the browser so that it can invoke the callback on Live Assist.

 

Related articles