- 25 Sep 2024
- 5 Minutes to read
- Print
- DarkLight
23.3.1. Digital Routing Policies
- Updated on 25 Sep 2024
- 5 Minutes to read
- Print
- DarkLight
What is a Digital Routing Policy?
A Digital Routing policy is a new type of Routing Policy in Natterbox where you can control the routing for your Digital Communication. The Conversation Routing policies intention is to locate a User in which to connect the conversation to, typically using a series of logic to identify the most relevant User - for example, a Lead Owner.
How do they differ from Voice Routing Policies?
The key differences between Voice and Digital is simply what kinds of traffic routes through each ones. Voice handles voice traffic only whereas Digital can only handle digital traffic. In terms of functionality they are mostly the same in terms of logic you can utilise in your routing such as rules and querying data in Salesforce, the main apps that are different are the distribution apps. For example, in the Voice world you would have a Call Queue but in the digital world you would have a Digital Connect.
Digital Routing Policy Apps
Digital Only Apps
The following apps are only available in Digital Routing Policies.
Name | Description | Purpose |
---|---|---|
Digital Connect | Connects the conversation to a User | To specify a User that the Digital Conversation will be routed to. |
Assign Records | Assign records to the conversation | To assign records to the conversation for reporting and conversation management. |
Block Message | Block the message from being delivered | To block the message from being delivered and provide a reason why. |
Update Message | Update a message before it is delivered | To update and manipulate a message before it is delivered. |
Existing Routing Policy Apps
The following apps are also available to provide the ability to Query, Crate, Update data in Salesforce and then utilise this data to route appropriately.
Types of Digital Routing Policies
Conversation Routing (Pre Route)
The purpose of this type of routing policy is to determine which User the conversation is distributed to. These policies are only fired when a message comes in for brand new conversation that is not already assigned to a User.
These policies are typically created but there is a Default Inbound that comes as a system policy (more info below) that acts as a catch all if an address has not been set up in a routing policy.
More information can be found here.
Contact Lookup
The purpose of this type of routing policy is to do a lookup and return Salesforce records that are relevant to the conversation. Typically this is achieved by using the inbound address and looking up standard objects such as Contacts or Accounts however this can also use custom objects if required.
You will only have 1 Contact Lookup policy which is created by default as a System Policy (more info below) and it is separated on a Channel Type basis allowing you to have different logic depending on the channel type.
More information can be found here.
Live Message Routing
The purpose of this type of routing policy is to allow you to manipulate your messages before they are delivered. The live message routing policies allow you to block or update a message before it’s delivered. For example, you may want to add a signature to every message before it’s sent so your customers are informed for who they are speaking with. You can also utilise Live Message Routing to take the message content and store this in Salesforce on a specific record.
More information can be found here.
Event Routing
The purpose of event routing policies are to be able to initiate a routing policy when a certain event happens - for example a message is sent. This is similar to the Live Message Routing in that you can create Salesforce records with the message contents but event routing offers the ability to setup retry logic and conditions to add more resiliency to ensure no data is missed if for example data is unable to be inserted into Salesforce at that time.
More information can be found here.
Digital System Policies
A system policy is a policy that comes out of the box and typically contains system components that cannot be added to other policies, they are usually a unique component that can only exist once.
Below is a list of the system policies and their purposes that come out of the box which are preinstalled.
Default Inbound (Digital)
Contains the Catch All system components which are used when a Digital address that is not assigned to a User or a Routing policy receives a message for a brand new conversation. This can also be used as a policy for routing individual addresses if needed but it’s recommended to keep these separated for organisation purposes.
Default Contact Lookup (Digital)
Contains the Lookup system components for each channel type which are used when a message is received on the appropriate channel for a Contact we cannot identify. For example if a message is received from an address that hasn’t messaged in before this will fire the relevant contact lookup based on the channel type.
Digital Routing Policy Macros
The following Macros can be utilised in Digital Routing Policies to introduce logic based on the conversation or message as well as to utilise in storing data in Salesforce.
Macro | Description |
---|---|
$(DigitalDirection) | The direction of the message being sent, resolves to INBOUND or OUTBOUND. |
$(DigitalPayLoadText) | The text content of the message. |
$(DigitalChannelType) | The channel type of the message, e.g. SMS, WHATSAPP. |
$(DigitalIdentityAddress) | The digital channel address of the Contact that the message relates to. |
$(DigitalChannelAddress) | The digital channel address of the Agent that the message relates to. |
$(DigitalContactDisplayName) | The display name of the Contact. |
$(DigitalChannelGroupName) | The name of the Digital Channel Group that the channel is allocated to. |
$(DigitalChannelGroupDescription) | The description of the Digital Channel Group that the channel is allocated to. |
$(DigitalChannelGroupType) | The type of the Digital Channel Group, e.g. SHARED or PRIVATE. |
$(DigitalMessageDate) | The date that the message was sent or received. |
$(DigitalMessageDateUTC) | The date that the message was sent or receive in UTC. |
$(DigitalMessageDateEpoch) | The epoch timestamp of when the message was sent or received. |
$(DigitalConversationOwnerId) | The Owner Id of the Digital Conversation, if value is updated during routing this will resolve to the newest value. |
FAQ
What minimum Natterbox Salesforce package version must I be on?
It is typically recommended to always be on the latest stable version, but the minimum version for the Digital Routing Policies feature is 1.310. More information can be found here.
Can I have a Routing Policy that handles Voice and Digital traffic together?
Currently no, routing is split for Voice and Digital.