The CRM URL can make the use of variables. This can be specified in the IVR when using the object Save addit. info and user data and also in the ACD group CRM URL setting itself.
When semicolons, commas, apostrphophes or pipes (;,'|) are used in the additional info, it can cause the web client to miss events and not display calls.
DO NOT use these characters.
The variables are evaluated by the web server, before the URL is passed to the client.
Simple Variables
The following variables can be used:
Variable | Meaning |
---|---|
$RootNumber | Root-Number (Platform Destination) of the service number |
$ServiceNumber | Service Number (Name Field). |
$CustomerNumber | Customer Number of the Service Number |
$ParentCustomerNumber | Parent Customer Number of the Service Number |
$ContractNumber | Contract Number of the Service Number |
$BillingNumber | Billing Number of the Service Number |
$GroupNumber | ACD Group Number |
$groupname | ACD Group Name |
$CallerNumber, $caller | Caller Number |
$username | Agent Name |
$userfirstname | Agent First Name |
$useruid | Agent UID. |
Extended Variables
Extended variables can be used, which are retrieved from the User status in the ACD directly.
Replacement
With URL encoding
Using single curly braces URL encodes the string before inserting it into the URL.
Specify the fields as follows: ${Variable}
Without URL encoding
FROM RELEASE 3.30
Using double curly braces performs a direct replacement without encoding into the URL.
Specify the fields as follows: ${{Variable}}
Use Case
This can sometimes be necessary, if the server and protocol portion of the URL are needed to be variable. For example take the following URLs:
myprotocol://myserver1.jtel.de:1000/variable_part_1/application?param1=value1¶m2=value2
myprotocol://myserver2.jtel.de:2000/variable_part_2/application?param1=value1¶m2=value2
Imagine the server portion of the URL being variable - some users login to the first server, and some users login to the second server. The application part of the URL (after the final slash) is the same in both cases (the parameters will probably identify a particular record in the CRM system). So the first URL is to be used by user 1, and the second URL by user 2.
Clearly, before the call is distributed, the URL cannot be built. This means it must be built dynamically according to which user receives the call.
The server portion of the URL could be configured in the jtel user account, for example the nick name field or another appropriate informational field which is not required for the operation of the user account in the jtel system.
For example, the NickName field could be specified as follows:
User 1: myserver1.jtel.de:1000/variable_part_1
User 2: myserver2.jtel.de:2000/variable_part_2
Then the CRM URL could be specified as follows:
myprotocol://${{NickName}}/application?param1=value1¶m2=value2
Available Extended Variables
${Variable} |
---|
UID |
Name |
FirstName |
NickName FROM RELEASE 3.30 |
TelActive |
dtCallStart |
ServiceNumbersName |
ServiceNumbersName2 |
AcdGroupsName |
AcdGroupsGroupNumber |
bMandatoryTransactionCode |
AcdConfigurationGroupsName |
ANumber |
WaitingTime |
ContactClass |
ContactNumber |
ContactName |
ContactPostCode |
ContactCity |
StatisticsPartAID |
CustomerNumber |
ParentCustomerNumber |
ContractNumber |
BillingNumber |
ContactTel1 |
ContactTel2 |
ContactTel3 |
ContactTel4 |
ContactTel5 |
ContactEmail |
ContactFirstName |
ContactLastName |
ContactCustomerNumber |
UserData |
DiallerCampaignsID |
DiallerContactsName |
DiallerCampaignsClientService |
DiallerContactsAmount |
DiallerContactsFirstName |
DiallerContactsComment |
DiallerContactsManufacturer |
DiallerContactsModel |
DiallerContactsTag |
DiallerContactsDtBeginDate |
DiallerContactsDtEndDate |
DiallerCampaignsName |