This section demonstrates how to build a workflow that uses an LDAP connection to a Windows Active Directory domain to retrieve phone numbers and transfer the caller to the retrieved extension.
This example is composed of a main workflow and a subroutine that contains an LDAP query. The caller is presented with a menu that prompts them to enter the extension of the party they wish to reach. If they know the extension they can dial it at any time or they can dial by name (by pressing 1) or choose to speak to the operator (by pressing 0). When the caller chooses option 1, the workflow is directed to the Dial By Active Directory (DialByAD) subroutine. Subroutines are recommended when a call process contains many activities or repeating tasks. In this case, the DialByAD subroutine contains several activities. Segregating it from the main workflow simplifies the process.
The following figure depicts the final, post-configuration version of the Dial Active Directory workflow.
The following figure depicts the final, post-configuration version of the DialByAD subroutine.
Before creating the workflow, you must configure the required variables and prompts.
Create the following list of variables along with their associated variable type. (See the following figure.)
After creating the variables, configure applicable prompts as shown in the following table.
Prompt Name | Script |
---|---|
DialAD – Main Menu | Thank you for calling. If you know the extension of the party you wish to reach, dial it now. To dial by name, press 1. For operator assistance, press 0. |
DialAD – Name from Dialpad | Using your touchtone keypad, please type the last name of the person you wish to reach, followed by the pound (#) sign. |
DialAD – Did you mean ... Note:
This prompt references the variable DAD_TempWav created earlier |
<DAD_TempWav> If this is the person you want to reach, press 1. If not, press star (*). |
The next step in creating the Dial Active Directory workflow is configuring the Menu activity.
See the following figure for suggested configuration settings.
The In Between Digit Delay function allows the system to wait for one second (default value) after hearing the first DTMF tone from the caller to see if another digit will be pressed before processing the call.
It is important to give each menu option branch an appropriate name as doing so simplifies the troubleshooting process when interpreting log files.
See the following figure.
This sets the entry that is received by the Menu activity as the transfer point.
Following this naming convention simplifies the troubleshooting process when searching through log files. See the following table for an example of best practice naming conventions.
Menu branch | Naming convention |
---|---|
Timeout | brmnMain1OPTTIME |
Invalid | brmnMain1OPTINV |
Failure | brmnMain1OPTFAIL |
Now that the main Dial Active Directory workflow has been configured, the DialByAD subroutine must be configured and added to the overall workflow.
If the caller knows the last name of the person they are trying to reach, they enter the matching digits in their dial pad. The dial pad compare feature is used to support this search function. The first step in being able to access this functionality is to collect the digits. This is done via a Collect Digits activity within the subroutine.
See the following figure.
Menu branch | Naming convention |
---|---|
Success | brcdGetLastNameSUCC |
Timeout | brcdGetLastNameTIME |
Invalid | brcdGetLastNameINV |
Failure | brcdGetLastNameFAIL |
The Collect Digits settings window opens.
The Variable should be unique to this workflow and be of the Variable Type Number. In this case, the variable <<DAD_Ext-Lookup>> is used.
This example uses a greeting that asks the caller to enter the last name of the person they are trying to reach by using their dial pad and pressing pound (#) when finished. The settings and greeting verbiage you choose are dependent on your environment and needs.
This example performs a lookup based on the last name of the employee in Active Directory. However, the procedure can easily be converted to use the first name or a different value altogether. When a caller successfully enters digits they are branched down the Success branch in the Collect Digits activity. In the Success branch, a Query to Active Directory is inserted to search for the requested employee. Prior to this action, a new data provider must be created.
This example connects to a local domain labeled 'PFSE Domain'.
This example queries based on the employee’s last name and returns their extension to which the call is then transferred. The Last Name, Display name, and Telephone number fields from the user object in Active Directory are accessed. In addition, the objects will return a .wav file so the names can be read back to the caller. It is suggested that each employee record their name to use as a customized .wav file. In this example, the customized employee name .wav files are stored in the Telephones tab in Active Directory. Note that this location must be accessible from the IVR Routing instance performing the query and readback. (See the following figure.)
This example uses 'Get User from AD – PFSE.LOCAL' and 'qrPFSEAD' respectively.
This example uses PFSE Domain.
An advanced query is necessary in this example to enable the return of multiple variables. If there was only a need for a single variable, a simple query would suffice.
The value of ‘76’ is translated into the following when using the dialpad compare feature: p, pn, Po, Q, Qm, Qn, Qo, R, Rm, Rn, Ro, S, Sm, Sn, So.
The command runs and the Database Lookup window for the Advanced Query opens.
In this example, CN is used for the common name of the Active Directory object (display name in Active Directory) and telephoneNumber for the extension of the user being queried. The information from the Telephones tab is also returned as it contains the location of the .wav file to be played. (See the following figure.)
Configuring the parameter assignment with a variable replaces the query with the appropriate run-time information. (See the following figure.)
Now that information has been retrieved via the LDAP query, the process loops through the results until the correct one is found. The customized employee name .wav file is played and the caller is asked if that is the individual they want to reach. Once the correct name is found, the caller is transferred to that destination and the workflow is terminated.
This example uses 'Did you mean…?' and 'mnDidYouMeanQ', respectively.
Menu branch | Naming convention |
---|---|
1 | brmnDidYouMeanQOPT1 |
Timeout | brmnDidYouMeanQTIME |
Invalid | brmnDidYouMeanQINV |
Failure | brmnDidYouMeanQFAIL |
Activity | Name | System Name |
---|---|---|
Play | Transferring your call | pfTransferring |
Transfer | Xfr To Extension | xfrToExt |
Transfer Branch | Failure | brxfrToExtFAIL |
Hang Up | Hangup After Transfer | hgTransfer |
This example uses a prompt called 'DAD – Transferring' that plays a .wav file that says: 'Transferring your call now.'