Parameters allow to store information such as DTMF input, variables, or any other text-based information in a custom field name / value pair. Parameters can then be selected in other areas of Nimbus such as Workflows, e.g. to store customer inputs and route a call accordingly.
Adding Parameters
- Log into Nimbus Administration.
- Open Configuration > "Service" > "Parameters".
- Click “Create”
- Specify details for your parameter:
- Click "Save".
| Field | Description | Max length |
|---|---|---|
| Name | System name or label as the parameter is visible in the Nimbus UI e.g. within other selection pulldown menus and listings. | 64 characters |
| Organization Unit |
The Organization Units (service) to which this parameter will be made available for. 💡 Other services / OU's may not see or access this parameter. A Tenant admin can re-assign the parameter to a different OU or make it available tenant-wide. |
System defined |
| Default value |
The default value can be any content. It will be left unchanged if the caller hasn't made an input. You can check for the default in "Check Parameter" Workflow Activity and react accordingly. 💡 You can also leave this field empty (Empty string, not null) |
5120 characters |
| ID |
🔍 Generated automatically on creation, this ID is the systemic name for the variable. Please note:
|
64 characters |
☝Caution: (Productive) Parameter deletion and changes
-
Parameter Deletion: Exercise caution when deleting parameters. Nimbus cannot check if a parameter was actively used in either a Power Automate Flow, as part of a context URL or an internal workflow.
When you delete an in-use parameter, the behavior is as follows:- In Workflows: The parameter is replaced with “N/A” but the ID is retained. The parameter will not have a default value.
- In Conversation Context: the deleted parameter will not be resolved (as part of an URL) anymore. Service Call Templates / Direct Call Templates will not execute (GET/POST requests) correctly anymore.
- In Flow Actions: the parameter ID is treated as “custom” and thus created during the flow run, but you will not have any default values to evaluate.
- Parameter Changes: Except for their ID, which gets fixated on parameter creation, Parameter clear names, defaults and Organization Units can be changed by any administrator at any time. To avoid issues, clearly distinguish your parameter names (e.g. by department, use case). When working together with other administrators, agree on unified parameter naming and OU placement to avoid unintended changes.
Workarounds:
→ When you delete a productive parameter on accident - and you still know its ID - you can re-instate it with a new parameter using the same unique ID. However, consider the former Organization Unit as well so the parameter remains accessible.
→ If you need to delete a productive parameter (e.g. changing to a new ID), check all related usage scenarios (Flows, Workflows, Context) first and then switch to the alternative.
Using Parameters
Parameters can be used in the following areas:
Area |
Usage within |
|---|---|
| Extension Service Settings |
My Sessions UI customization:
|
In Workflows
In your Workflows, certain Workflow Activities can make use of parameters:
- "Voice Message"
- "Input customer"
- "Input customer (advanced)
- "Collect Information"
- "Check Parameter"
💡 For example, you can use a parameter "Collect Information" activity, e.g. to collect a DTMF input from your callers. Following up, the input can then be evaluated with the "Check Parameter" activity, e.g. to route a call or play an announcement based on a regular expression evaluation. If a parameter was left blank (without default) and the customer left no input, you can react to this case as well.
Related Pages
Refer to our Power Automate Use Cases for further examples:
In Voices Messages
As part of the workflows, "Voice Message" a previously filled custom parameter can be part of a dynamic message.
Related Pages
Refer to our Power Automate Use Cases for further examples:
In Power Automate
You can also use your custom parameters in a Power Automate flow, e.g. to directly interact with other external systems:
- The Nimbus connector will update with the Trigger Events > When a Task Changes State > “Parameter Updated”
-
Flow Actions allow to use the custom parameter in the following form:
CustomContextParameter.<ID>… with <ID> replaced by the unique ID when you created the parameter (→ see above chapter "Adding Parameters").
Related Pages
Refer to our Power Automate Use Cases for further examples:
In Context URLs
When creating Conversation Context items to open alongside a call, custom parameters can be used for form part of an URL. This can be useful to open external systems, e.g. for Ticket creation purposes, using Custom or System parameters as part of the URL.
Related Pages
Refer to our Power Automate Use Cases for further examples:
In the Nimbus UI
Parameters can also be configured to be shown in the Nimbus UI, e.g. in My Sessions as part of the . This is steered via Extensions Service Settings of your Services.
Questions and Answers
INC Fields and Parameters explained
🤔 What are the differences between Custom System Fields and Parameters and User created Custom Parameters?
In a nutshell, all parameters are placeholders containing one or multiple fields each with a name (key) and value (content). The difference in naming those parameters with different prefixes stems from their purpose:
- Field = Individual piece of information, identified by its field name. One or multiple fields collectively define the values of a parameter.
- Parameter = Used to store data and control system behavior. Complex Parameters can have names consisting of multiple parts, e.g. $(Customer.TelNumbers.Mobile), $(Customer.TelNumbers.Home), each containing
- System Parameter = Hardcoded parameter ID, hardcoded field names, read-only field values, empty by default.
- Custom Parameter = Flexible parameter ID, Flexible field names, variable field values with an (optional) default value.
Show me some examples…
Parameters and their fields can be referenced via their names throughout Nimbus and also in external Systems using Nimbus Power Automate Connector. Nimbus users can expand this selection of system parameters by their own custom Parameters, which allow “default” values to be set for later checks if Nimbus (or external Systems) have actually correctly written updates.
Parameter examples
From an system point of view, the parameters are storage placeholders for different purposes. In Nimbus there are two types of parameters to know:
| Parameter Type | Parameter name (Placeholder) | Example field names and values |
Name set | Field Value Set |
Purpose |
|---|---|---|---|---|---|
| System parameter | $(MicrosoftCallerId) |
Callername: Anonymous CallerNumber: |
hardcoded | by System | Caller Identification for the system to process. |
| $(Customer.DisplayName) | Customer Display Name: Jon Doe | hardcoded | by System | After system processing, showing caller Identification to Nimbus users, e.g. My Sessions UI. | |
| Custom parameter | $(Customer.CustomFields.<AnyName>) | Occupation: Taxi Driver | user defined | by User | Context, e.g. a retrieved Customer CRM ID used in Extensions Service Settings as part of an URL shown as extra field. |
| $(CustomContextParameters.<AnyName>) |
IVR Choice: “0_Unspecified” IVR Choice: “2_Support” |
user defined | by User | Store caller inputs, e.g. type of problem, IVR choice taken and stored in a Workflow Activity. |
💡Learning: Parameters can store anything and may be overwritten (if not hardcoded and read-only). They may be used to steer system behavior or contain custom context information.
Field examples
From a user point of view, the fields of a parameter can appear identical, e.g. an “Customer Address” field, but those fields can originate from different sources (CRM, Address book) via Flow Actions.
| Field Type | Field name | Name set | Field value set | Value read by user… |
|---|---|---|---|---|
|
Call attributes (see System Parameters > Call Data > Caller Data Fields) |
callId | hardcoded | by System | as Parameter with hardcoded value |
| customerId | hardcoded | by System | as Parameter with hardcoded value | |
| customerAddress | hardcoded | by user via Parameters | as Parameter with user-controlled value | |
| customer.customFields | user defined | by user using Parameters | as Parameter with user-controlled value | |
|
(see System Parameters > Address Book Fields) |
addressBookId | hardcoded | by System | as hardcoded value |
| customerId | hardcoded | by user in a free form using “Address Book” handling Flow Actions. | as user-controlled value | |
| customerAddress | hardcoded | as user-controlled value | ||
| customFields | user defined | as user-controlled value |
💡Learning: Fields can have identical names, but come from different parameters. A field refresh is done via Flow Actions at certain Trigger Events in your Workflows.
Usage Examples
Using the Flow Actions in the Nimbus Power Automate Connector parameter fields and their values can be updated. This can be any static or dynamic value, e.g. retrieved from external systems.
As previously mentioned, a mixture of system and custom fields are part of the JSON object as in a key/value pair. The customFields in this example are forming the bottom part of an Address Book which was previously created in the Nimbus configuration.
[
{
"addressBookId": "97ff7cf8-ee53-4de9-aca3-1287d2fea51e",
"id": "eb30d621-a7cc-4fb3-b0f1-a046ed04e1df",
"externalId": "03fac1cb-f00b-4521-b8c1-4c168752a7f5",
"firstName": "Alessandro",
"lastName": "Volta",
"displayName": "Alessandro Giuseppe Antonio Anastasio Volta",
"company": "Tenant Address Book",
"jobTitle": "Scientist",
"imAddresses": [],
"emailAddresses": [],
"businessPhones": [],
"mobilePhones": [
"123456789-10"
],
"homePhones": [],
"userPrincipalName": "avolta@lunifico.cloud",
"addresses": [],
"customFields": [
{
"name": "Achievements",
"value": "Invented the battery"
},
{
"name": "Birth Year",
"value": "1745"
},
{
"name": "Language",
"value": "Italian"
}
]
}
]🔎 Address Books are just an example for storage for your parameter data. Here are some Power Automate Use Cases for your inspiration:
- Use Case - Storing External CRM Data in Custom Parameters
- Use Case - Adding External Address Books via Power Automate
- Use Case - Retrieving Azure AD Fields via Agent Token
- Use Case - Looking Up a Caller to Open Dynamics 365 Contact Context
- Use Case - Creating a ServiceNow ticket based on user input
- Use Case - Looking up caller data from a simple Excel list
- Use Case - Working with Blacklists or Whitelists in Nimbus.
🤔 What are the default values in a parameter for?
If a parameter is never set in a session, the default value is used and can be part of all examples above, e.g. to define a "Default" path in your call flows.
- Within the Microsoft Power Automate Connector:
- On an incoming call Nimbus adds predefined Conversation Context Parameters of the service and higher level (tenant) to the actual CustomContextParameters list, each with their default values.
- This will occur from the beginning with the first Trigger Event.
🤔 How long are my parameters stored?
Custom Parameters are kept as long the customer session is ongoing - even after workflow transfers to other services. The parameter is cleared when the session concludes with a result, according to the Nimbus Reporting Model.
💡 You can change this by enabling Store Conversational Context Data in Extensions Service Settings.
Learn more about storing context data…
INC Store Context Data
GDPR After a service task has concluded, any historic session and customer context data – e.g. as shown in the My Sessions widgets – will by default not be stored by Nimbus.
While disabled:
⮑ the "Session Details" of any historic task records will show “Not Available” instead within My Sessions and Historical Sessions.
⮑ Previous custom Parameters / and Conversation Context items (e.g. Customer details or URLs dynamically retrieved and formed via Nimbus Power Automate Connector) will not resolve or open correctly anymore.
This storage behavior can be changed by enabling the “Store Conversation Context Data” in Extensions Service Settings:
☝ Note that the “Store Conversation Context Data” option is disabled by default as potentially sensitive caller data can appear in historical records and seen by Administrators (e.g. via Historical Sessions). Therefore…
- … the sections below should be read carefully to understand its effects.
- … involved parties should note that this setting has no retroactive effect, meaning that only data after enabling this setting will get stored for the retention period.
- … the setting must be enabled individually per service (OPT-IN).
🤔What happens when I enable this?
☝Task information / Session detail data is stored per service session on call termination (either transfer by workflow or user).
- Within the UI of My Sessions and Historical Sessions
- Custom (user created) Parameters
- System Fields and Parameters (both “Custom” and "System" parameters like Call ID, Service UPN, etc.)
☝ Restrictions on concluded sessions (e.g. within My Sessions) apply as follows:
- ... the "Embedded Context widget" will resolve with the currently configured URL with a previously saved call information. This means that also historic sessions will use the link currently configured in the Extensions Service Settings .
- ... the separate "Open Context" link remains clickable if at least one Conversation Context URL is currently configured.
- ... the "Session Details" widget will still show Custom and Customer parameters if available.
☝ Not stored (regardless of setting) are:
- Default "My Session Parameters" user data is not stored as it is always retrieved dynamically from the internal user directly of your Tenant.
🤔What happens in service transfer scenarios?
Nimbus always stores live context on transfer to services (either initiated by workflow or user). The "Store Conversation Context Data" option will have no impact there.
☝ However, enabling the "Store Conversation Context Data" setting will cause such live context data to be stored as historical record after call termination. This also applies on each transfer between services, creating a historical record entry for each service that has the setting enabled.
In an example transfer scenario this may cause historical data to “accumulate” between services, as data gets updated and appended.
Example - Transfer from Service A to B to C:
| Parameter | Service A ► transfer to | Service B ► transfer to | Service C |
|---|---|---|---|
| Customer Name | John Doe | John Doe | John Doe |
| Spoken Language | German | <Not Relevant> | <Not Relevant> |
| Gender | <Not Relevant> | Male | <Not Relevant> |
| Ticket ID | #1111 | #3151 (overwritten Ticket Parameter) | <Not Relevant> |
| “Store Conversation Context Data” enabled | ✅ | ⬜ | ✅ |
| Stored Historical Sessions data shown | John Doe (1) German Not used #1111 |
John Doe (1) Not available (not stored) Not available (not stored) |
John Doe (1) German (from Service A) Male (from Service B) #3151 (from Service B) |
(1) The user name will always be resolved from a UPN / PSTN when it was found within the existing O365 user directory.
🤔How long is data being stored?
- Caller info is updated on a “terminated” workflow Trigger Events and stored for a maximum of 30 days for the last available service session (in case of transfers).
- Conversation context data will also be stored for failed/killed calls.
- After 30 days the data is cleared. This also happens when either the service or tenant is being unprovisioned when Uninstalling Nimbus.
☝ Best Practice: If you wish to store critical or personal session data permanently, you need to do so during an active session and within a system of your choice (e.g. a CRM or Database).
🔍 Whitepapers: You can also learn more about the data retention policy in our whitepapers, available in the Documents section.
🤔 A lot of information - can I get an example?
Sure. Let's explore lifecycle and possibilities with custom parameters in an example.
Learn more…
First we created several custom Custom Context parameters for the DOC team. To make their usage and intent clear, the “Name” field has gotten a prefix, which also helps with later search.
Learnings:
- As soon as a caller session is started in Nimbus, the Custom Context Parameter object is created and holds the list of all customer context parameters for the related Organization Unit.
- If you leave the "Default Value" of your Parameter empty, it is also initialized with a null value in Nimbus.
💡 Note that an empty parameter, “Null” or "0" are not the same in validation checks. - We can use the "Collect Information" workflow activity to set the value of Custom Context Parameter.
- We can use the "Parameter Updated" Trigger Event Power Automate Flow to react to the update event generated by the "Collect Information" workflow activity and use the value in a flow.
- We can follow up upon the trigger with a Flow Action “Update task” to set or update any values of our Custom Context Parameters.
💡 In this example we could set the “DOC_isVIP” flag to show in My Sessions UI for the receiving preferred, user Rachel Smith.
What happens in the background?
In Power Automate, the JSON structure of the data object holds all custom context parameters and their current values.
💡We can chain multiple Trigger Events that react to your workflow, e.g. when “Terminated” was reached we could check the survey parameter again to see if the user made any changes and return that value to the previously handling agent to see how well they have done.
💡The fields UpdatedParameterName and UpdatedParameterValue indicate which custom parameters have updated.
"CustomContextParameters": {
"DOC_Survey": "2",
"DOC_ClientId": "1234567",
"DOC_PreferredAgent": "SIP:dave@company.com",
"DOC_isVIP": "true"
},
"UpdatedParameterName": "DOC_Survey",
"UpdatedParameterValue": "2"
}Related Pages
Refer to our Power Automate Use Cases for many examples, such as: