This guide is intended for advanced Salesforce admins. For Salesforce education, contact Salesforce directly or use trailheads for specific knowledge.
These solutions will enable a user to redirect their DDI calls when they are out of office to another user of their choice.
Using a Custom Salesforce Object
This requires a Salesforce admin to set up.
How to set this up
Create a new custom salesforce object called Number Routing with the following fields:
Natterbox User (Lookup, filter on active Natterbox Users)
Divert Number (Phone)
Start Time (Date/Time, value cannot be after the End Time)
End Time (Date/Time, value cannot be before the Start Time)
Active (Formula Checkbox, true if current time is between start and end time)
Reason (Picklist, example values: Annual Leave, Training Day, Sick Day…)
Notes (Text Area)
There are 2 options to choose how to do the next step:
Create an availability state so the policy would query the availability state and then check if there is an active DDi redirect
Only check if there is an active DDI redirect
Once this has been decided, go to the DDI Calls Routing Policy and add the following steps:
Cut the existing connection between the DDI Numbers container and the Connect a Call container.
Add an action container with a query app.
Set the following values on the query app
Result Set = DDI_Redirect
Trigger When = Only check Records found
Record Type = Number Routing
Filter results: Natterbox User = ? and Active = True
Return Fields = Divert Number
Add a new Action container with a Connect a Call app and connect from the top note of the query container.
Set up the connect a call container as follows:
Name this item = Connect to Divert Number
Action = Phone Number
Number = Divert_Number - this can be found by clicking the macro button on the field and then going user defined
Connect the original connect a call container to the bottom node on the redirect query container. This is the path calls will go down as normal if there is not active ddi redirect record.
How to manage this process
Each Natterbox users owns their own record so they can edit it
Sharing rules enable team leads and admins to change other agents records
Salesforce team could make a UI to manage it
It can be reported on using standard SF reports
The object can be used for other processes for example blocking nuisance numbers. These records can be differentiated by using record types on the object.
Using a Natterbox Routing Policy
This process needs an experienced Natterbox admin with Salesforce admin access.
How to set this up
Create a new routing policy and name it ‘DDI Redirect’
Add an extension container and set an extension which will be the number that everyone has to dial to get to the DDI redirect interface
Add in an action container with a query app to find the user that is calling in.
Next add a switchboard container. Here I suggested adding 4 switch options
Press 1 to redirect own calls
Press 2 to redirect other user’s calls (an admin pin will be needed to do this)
Press 3 to change back your own calls
Press 4 to change another user’s calls back (an admin pin will be needed to do this)
From here you can customise the paths as you would like. For example, with for press 1, add these steps:
Connect a switchboard app with a Get Info app
Speak phrase: Please enter the extension of the agent you wish to redirect your calls to.
Digit pattern: d\d\d\d\
Add an action app with a query app to query the user that the extension entered belongs to.
Record type = Natterbox User
Filter results: User Extension = *value needs to be the entered extension*
Return fields: Active, Name, Record ID, Salesforce User
Add a speak app to that action container and add in ‘Sorry we could not find an active user with that extension, please try again.’
The bottom of that container should go back to the previous switchboard container
The next app is to confirm the choice. Add a switchboard container with a switch item app. Add the phrase “Press 1 to confirm you would like to redirect your DDI calls to *macro for the user you have just queried*. If you have changed your mind, end the call.”
Add an action container with an update record app
User Type = User
Record Id = $(UserID)
Set values: *Update the redirect field on the salesforce user*
Add another container with a speak app and a notify app
Set the speak app to say “You have successfully redirecting your DDI to *insert marco*. You can redial the extension to change this.”
Set notify app to email to an admin or team lead with something like this
“The Natterbox User: $(CallerUserAgent). has redirected their DDI calls to the agent: *macro for ddi redirect user*.”
The rest of the paths can be configured in a similar fashion either to add in an admin pin so only admins can change other users or to change a user back to receiving their own DDIs.
How to manage this process
An admin pin needs to be decided and made a note of.
An extension needs to be agreed on
Report on this use salesforce reports
Emails can be configured so admins and team leads get notified when a change is made
Pros and Cons
Method | Pros | Cons |
|---|---|---|
Salesforce Custom Object | More scalable - redirect records can be data-loaded | Will need a salesforce admin to set this solution up |
Access can be managed using Salesforce’s sharing settings/rules | ||
A UI could be created using salesforce flows to manage this process | ||
This object can be used for other processes by using record types, for example numbers you want to block | ||
Salesforce at creating and manipulating data and Natterbox is better at querying and utilising data. | ||
Maintained in salesforce so can be reported on | ||
Natterbox Routing Policy | No new custom salesforce object | Natterbox is better at utilising data than creating |
Harder to manage as you have to make a call for each user you want to change the divert for. | Less scalable |