How to Redirect one DDI to another DDI

Prev Next

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

  1. Create a new custom salesforce object called Number Routing with the following fields:

    1. Natterbox User (Lookup, filter on active Natterbox Users)

    2. Divert Number (Phone)

    3. Start Time (Date/Time, value cannot be after the End Time)

    4. End Time (Date/Time, value cannot be before the Start Time)

    5. Active (Formula Checkbox, true if current time is between start and end time)

    6. Reason (Picklist, example values: Annual Leave, Training Day, Sick Day…)

    7. Notes (Text Area)

  2. There are 2 options to choose how to do the next step:

    1. Create an availability state so the policy would query the availability state and then check if there is an active DDi redirect

    2. Only check if there is an active DDI redirect

  3. Once this has been decided, go to the DDI Calls Routing Policy and add the following steps:

    1. Cut the existing connection between the DDI Numbers container and the Connect a Call container.

    2. Add an action container with a query app.

    3. Set the following values on the query app

      1. Result Set = DDI_Redirect

      2. Trigger When = Only check Records found

      3. Record Type = Number Routing

      4. Filter results: Natterbox User = ? and Active = True

      5. Return Fields = Divert Number

    4. Add a new Action container with a Connect a Call app and connect from the top note of the query container.

    5. Set up the connect a call container as follows:

      1. Name this item = Connect to Divert Number

      2. Action = Phone Number

      3. Number = Divert_Number - this can be found by clicking the macro button on the field and then going user defined

    6. 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

  1. Create a new routing policy and name it ‘DDI Redirect’

  2. 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

  3. Add in an action container with a query app to find the user that is calling in.

  4. Next add a switchboard container. Here I suggested adding 4 switch options

    1. Press 1 to redirect own calls

    2. Press 2  to redirect other user’s calls (an admin pin will be needed to do this)

    3. Press 3  to change back your own calls

    4. Press 4 to change another user’s calls back (an admin pin will be needed to do this)

  5. From here you can customise the paths as you would like. For example, with for press 1, add these steps:

    1. Connect a switchboard app with a Get Info app

      1. Speak phrase: Please enter the extension of the agent you wish to redirect your calls to.

      2. Digit pattern: d\d\d\d\

    2. Add an action app with a query app to query the user that the extension entered belongs to.

      1. Record type = Natterbox User

      2. Filter results: User Extension = *value needs to be the entered extension*

      3. Return fields: Active, Name, Record ID, Salesforce User

    3. 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.’

    4. The bottom of that container should go back to the previous switchboard container

    5. 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.”

    6. Add an action container with an update record app

      1. User Type = User

      2. Record Id = $(UserID)

      3. Set values: *Update the redirect field on the salesforce user*

    7. Add another container with a speak app and a notify app

      1. Set the speak app to say “You have successfully redirecting your DDI to *insert marco*. You can redial the extension to change this.”

      2. 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*.”

  6. 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