Conversation access interceptors
Conversation access interceptors let your organization integrate third-party systems to approve or reject attempts to access Unblu conversations. This is useful if you want to restrict who has access to Unblu conversations based on permissions defined in your CRM, for example.
What is access?
Before describing how to configure conversation access interceptors and use them in Unblu, it’s important that you understand what it means to have access to a conversation.
Granting access to a conversation is the third and final step of a process that starts with the person becoming a participant in the conversation.
The next step is for the person to join the conversation. This may involve a formal onboarding process, depending on how the template for the conversation is configured.
Once someone has access to a conversation, they have access to the details and contents of a conversation in some form. This might be in an Unblu UI, such as the Floating Visitor UI or the Agent Desk. Access may also take place in some other way, such as the Unblu mobile SDK or JavaScript API.
The following actions are examples of a person accessing a conversation:
-
An agent opens a conversation from their queue in the Agent Desk.
-
A visitor opens an archived conversation in the Floating Visitor UI.
-
A supervisor retrieves a conversation from the conversation history with a call to the web API endpoint
/conversationhistory/{conversationId}/readusing a third-party application.
The following actions aren’t accessing the conversation and don’t trigger any conversation access interceptors:
-
An agent opens their inbox in the Agent Desk.
-
A visitor receives a push notification about a new message in an ongoing conversation.
-
The Agent Desk displays an invitation to a conversation for the agent to join.
Note that Unblu checks whether there’s a conversation access interceptor it has to call every time a person tries to access a conversation, not just the first time they do so.
Creating conversation access interceptors
There are two ways to create and manage conversation access interceptors:
-
In the Account Configuration interface.
-
Through the various web API endpoints, such as
/conversationaccessinterceptors/create, exposed by theConversationAccessInterceptorservice.
Whichever method you choose, conversation access interceptors always have the same features:
-
A name. Each conversation access interceptor must have a unique name within the Unblu account.
-
An optional description.
-
The interceptor’s order, which specifies the interceptor’s position in the order that Unblu calls the interceptors in. If two or more file interceptors have the same order, the order in which Unblu calls them isn’t specified.
If the order the interceptors are called in isn’t important to you, you can assign them all the same order, for example 0.
-
A timeout that defines the time the interceptor must respond in. If it doesn’t, Unblu treats the interceptor as unreachable and proceeds as defined by its timeout behavior.
-
The interceptor’s timeout behavior. If the interceptor doesn’t respond within the defined time, Unblu behaves as specified here. There are two options:
-
REJECT: The access request is rejected. -
CONTINUE: The access request is approved.
-
-
The endpoint URL where Unblu sends the
outbound.conversation_access_interceptor.new_accesswebhook for the access request to be evaluated. -
An optional secret key to verify that calls to the webhook endpoint are coming from the Unblu Collaboration Server.
-
The type of access requests the interceptor should review. Interceptors can be used to review requests of one or more of the following types:
-
Access as a visitor participant
-
Access as an agent participant
-
Access as a ghost participant: an agent with an active participation in the conversation is requesting access as a ghost
-
Ghosts without a participation in the conversation: an agent with no participation in the conversation is requesting access as a ghost
-
Configuring conversation access interceptors
To use a conversation access interceptor, you must enable it in the CONVERSATION_TEMPLATE scope. There are two configuration properties:
-
com.unblu.conversation.access_interceptor.enableAllConversationAccessInterceptors enables all of an account’s conversation access interceptors for conversations based on the conversation template in question.
-
com.unblu.conversation.access_interceptor.conversationAccessInterceptorIds lets you choose which conversation access interceptors to enable for conversations based on the conversation template in question.
If you enable all of an account’s interceptors with the first configuration property, Unblu ignores the second property.
The messages that Unblu displays based on the conversation access interceptor’s response are defined in the following text properties:
-
com.unblu.conversation.access_interceptor.interceptResponse: Displayed when an interceptor denies access to the conversation.
-
com.unblu.conversation.access_interceptor.invalidResponse: Displayed when the response from the interceptor was invalid or caused an unexpected error.
-
com.unblu.conversation.access_interceptor.timeoutResponse: Displayed when an interceptor times out and the timeout behavior is set to
REJECT.
See also
-
For information on creating and managing conversation access interceptors in the Account Configuration interface, refer to the Account Configuration interface guide.
-
For information on web API endpoints related to conversation access interceptors, refer to the documentation of the
ConversationAccessInterceptorsservice in the Unblu web API reference. -
For information on conversation access interceptor webhooks, refer to the
ConversationAccessInterceptorssection of the webhooks documentation in the Unblu web API reference.