Use automation to pass parameters
As agents work with customers, information that is related to the conversation can be helpful in providing context that ensures that the agent can provide customers with the best and most personalized experience possible. For example, if a customer named Kenny Smith initiates a conversation, the agent should see a personalized greeting script such as, "Hello Kenny. Thank you for contacting us, my name is Agent Name. How can I help you today?" The personalized greeting takes contextual information, such as the customer and agent, to create a personalized experience.
Dynamics 365 Productivity Tools includes the automation dictionary, which maintains the contextual data for sessions. While creating templates and macros in the Omnichannel Administration app, you can pass parameter keys such as the title of a session, title of the notification, title of an application tab template, and custom parameter values for application tab types. These keys are replaced based on the contextual information that is available at the time of implementation.
Regarding the case of the previous customer greeting, the notification shows certain fields and values, which are called Field header and Value, respectively. In this scenario, Field header represents Customer Name and the Value of the header would be Kenny Smith.
Pass data parameters in macros and agent scripts
The two most common areas where you would see data parameters being used are with macros and agent scripts. When the agent runs the macro, the system replaces these parameter keys with the actual values based on the context of the session, channel provider, Microsoft Dataverse, and user actions. When the context is from a session, the macro action is run based on the information for a current session, where the information is obtained from an anchor tab or current tab that's in focus. For example, to create a case, you need to define the actions that contain the incident entity form and the GUID of the form (optional).
Types of context data parameters
The automation dictionary uses the context data parameters that are available from the following sources:
Context data from the channel provider - Context data from the channel provider such as Omnichannel for Customer Service or another channel provider. Context data from Omnichannel for Customer Service includes a pre-chat survey, visitor portal navigation, and so on.
Context data from user actions - Data that is populated when agents perform activities in the session, such as opening a new customer record, case, and so on.
Context data from Dataverse - Organizational data that is stored in Dataverse that you can fetch with the use of OData queries.
Context data from other macro actions - Action in a macro that generates context data that is consumed by other actions in that macro.
Automation dictionary formats to pass data parameter keys
The automation dictionary maintains the contextual data for sessions. The keys in the automation dictionary can be passed as parameters to the action in macros. The system replaces these parameter keys with the actual value based on the context of the session, channel provider, Dataverse, and user actions.
The automation dictionary supports the following formats:
Slugs - Replacement parameters that the system populates at runtime based on context.
OData queries - Gets the contexts that are available from Dataverse.
Static values - Hard-coded values that you update as your business requirements dictate.
Slugs
A slug is a replacement parameter that the system populates at runtime based on context. When executed the slug will be replaced with text that corresponds to the slug being referenced. For example, you can use a slug to fill in the case title of the case record that is associated with a conversation. You can use the following list of slugs only for macros and agent scripts, and to set an agent script as the default by using the agent script expression builder.
| Slug | Description |
|---|---|
| ${customerName} | The name of the customer who initiated the conversation. |
| ${caseId} | The unique ID of a case. The system displays the case ID only if a case is linked to the conversation. |
| ${caseTitle} | The title of the case. The system displays the title of the case only if the case is linked to the conversation. |
| ${queueId} | The unique ID of a queue. This alphanumeric string is displayed in the queue page URL. |
| ${visitorLanguage} | The language of the customer who initiated the conversation. |
| ${visitorDevice} | The device of the customer who initiated the conversation. |
| ${entityRoutingLogicalName} | The name of the entity, if the notification is for an entity record. |
| ${entityRoutingRecordId} | The unique ID of the entity record, if the notification is for an entity record. |
| ${customerEntityName} | The name of the entity (contact or account), if the customer is authenticated. |
| ${customerRecordId} | The unique ID of the entity (contact or account), if the customer is authenticated. |
${<name of the pre-chat survey questions>} |
All the pre-chat survey questions that are configured for a workstream will have the slug name as the name of the question. |
For more information on working with slugs in different scenarios, Slugs
For more information, see Use the automation dictionary to pass data parameter keys.