Messaging for InApp and Web (MIAW)

Salesforce provides many objects around the Messaging functionality related to the OmniChannel. Through this post, I will focus on only two objects to keep it simple in reaching the goal of this article. Join us to learn about Messaging for InApp and Web (MIAW) How to retrieve the logged in user details without ‘User Verification’.

MessagingEndUser: Messaging end user records represent a link between a messaging channel and a user.
MessagingSession: Represents a session on a Messaging channel.

(Source: Salesforce)

Messaging for InApp and Web (MIAW)

The OOTB behavior is that the MessagingEndUserId field will be populated with the Guest user Id, instead of the actual site user who initiated the chat message. The ‘User Verification’ option will not work with experience sites yet. For now, it is only for the external websites and the mobile apps.

Then how to retrieve the Id of the experience site user who initiated the chat?

Well, there is a simple and intuitive workaround. Salesforce provides a way to retrieve the logged-in user based on the component type the user is interacting with, such as VF page, Aura, and LWC. The MIAW is built on the Aura framework, Hence, we use ‘$SObjectType.CurrentUser.Id’ to retrieve the userId.

In this illustration, I am assuming that the MIAW is enabled in the experience site. If you are reading this, I assume that you already have knowledge on Messaging Settings, Embedded Service Deployments, Pre-chat and Hidden fields. If not, I will explain them in another write-up. Here are the steps to achieve the purpose of this article

Step 1: Add Custom Parameter

Setup – Messaging Settings – Your Messaging Channel – Custom Parameters. Create a custom parameter as shown below

Step 2: Add Parameter Mapping

The parameters mapped here are available in the Omni-channel flow

Step 3: Update the OmniChannel flow

Head to the Omni-channel flow which you are using for routing or any custom logic execution. Add a Get element and Select User object. The UserId field we setup in the above steps will be available here. Use this Id to update the associated MessagingSession and the MessagingEndUser records.

You might be wondering, how the UserId field is fetching the experience site logged in UserId. You will find the answer in next steps which fulfills the objective from the backend.

Step 4: Select the Hidden field

Setup – Embedded Service Deployments – PreChat

Under the available hidden field section you will find UserId which we just created. Add it to the Selected field section

Step 5: Add Custom JavaScript to the experience site

All Sites – Builder – Settings – Advanced – Header Markup. Add the following code snippet

<script>
    var userId;

function callPrechatAPI() {
    // get UserId of the logged in Experience Site User
    userId = $A.get('$SObjectType.CurrentUser.Id');
    console.log('Passing UserId = userId (currently Logged In User Id, or ' + userId + ')');
    // Send it!
    embeddedservice_bootstrap.prechatAPI.setHiddenPrechatFields({
        "UserID": userId
    });
}
//just incase
function trapButtonClick() {
    console.log('Looking for embeddedMessagingConversationButton...');
    var b = document.getElementById('embeddedMessagingConversationButton');
    if (b != null) {
        console.log('Found it, attaching to onClick event');
        b.addEventListener('click', callPrechatAPI);
    } else {
        console.log('No button yet; wait a second and try again');
        setTimeout(trapButtonClick, 1000);
    }
}
window.addEventListener("onEmbeddedMessagingReady", () => {
    console.log('Received the onEmbeddedMessagingReady event...');
    callPrechatAPI();
});
window.addEventListener("load", trapButtonClick); 
</script>

Now, It makes sense why I discussed the ‘$SObjectType.CurrentUser.Id’ above.

Voila!!, log in to the experience site and verify the MessagingEndUserId value is populated.