Home Nimbus Usage of Nimbus Configuration

Parameters

Parameters allow service administrators to store CRM information or caller DTMF input in a custom variable. Parameters can then be used in Workflows, e.g. to store customer or CRM system inputs and route a call accordingly.

Creation of a custom parameter

Adding Parameters

To add a new parameter, open "Configuration" > "Service" > "Parameters".
Click on “ Create ”
Specify details for your parameter:

Field	Description
Name	System name or label as the parameter is visible in the Nimbus UI.
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. ☝ Careful when using shared parameters.
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)
ID	🔍 Generated automatically on creation, this ID is the systemic name for the variable. Please note: It has to be unique in your tenant and cannot be changed after creation. A warning will be shown if the ID was already used. Special characters and white spaces are not allowed Cannot be saved empty

Save your Parameter.

Using Parameters

Parameters can be used in the following areas:

Area	Usage within
Workflows	Workflow Activities "Voice Message" "Input customer" "Collect Information" "Check Parameter"
Microsoft Power Automate Connector	Action "UpdateTask" CustomContextParameter.<ID>
Conversation Context	As part of a context URL: $(CustomContextParameters.<ID>)
Extension Service Settings	My Sessions UI customization: "Session Details" widget

Below are some examples for each area.

In Workflows

In your workflow you can update a parameter with the "Collect Information" activity, e.g. to collect a DTMF input from your callers. 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.

Parameters handled in a workflow

In Voices Messages

As part of the workflows, "Voice Message" a previously filled custom parameter can be part of a dynamic message.

"Voice Message" activity with a dynamic custom parameter

In Power Automate

You can also use your custom parameters in a Power Automate flow:

The Nimbus connector will update the parameter during Trigger Events.
The flow action "UpdateTask" allows to use custom parameter in the following form:

CODE
CustomContextParameter.<ID>

... with <ID> to be replaced by the unique ID when you created the parameter (→ see above "Adding Parameters").

💡 The Workflow activity "Collect Information" will update only the custom parameter, not cause a complete refresh of all parameters as a Trigger Event would-

In Context URLs

When creating Conversation Context to open alongside a call, custom parameters can be used for form part of an URL.

Context URL with dynamic custom parameter parts

Example: Parameter Lifecycle

Let's explore the lifecycle and possibilities with custom parameters in an example:

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.
We can use the "Collect Information" workflow activity to set the value of a Custom Context Parameter.
We can use the "Parameter Updated" Trigger Event within a Power Automate Flow to react to the update event generated by the "Collect Information" workflow activity and use the value in a flow.
The fields " UpdatedParameterName " and " UpdatedParameterValue " hold the name and value of the active " Parameter Updated " trigger event.
We can also use the Power Automate Action " UpdateTask " t o set or update the value of a Custom Context Parameter.

For our service "Sales Demo CH" we created five parameters:

Custom Parameter JSON

In Power Automate, the json structure of the data object holds all five custom context parameters and their current values.

💡 " UpdatedParameterName " indicates which one has been updated in the last " Parameter Updated " Trigger Event

 JSON
 
 "CustomContextParameters": {
 "Survey": "2",
 "ClientId": "5638872",
 "IsOnBlacklist": "false",
 "PreferedAgent": "SIP:dave@company.com",
 "IsVIP": "false"
 },
 "UpdatedParameterName": "Survey",
 "UpdatedParameterValue": "2"
}

Read our related Use Case - Storing external CRM data in custom parameters to learn more on this topic.

GOOD TO KNOW

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.

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 not be stored by Nimbus.

As a result:
⮑ 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 via Nimbus Power Automate Connector) may 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). The setting must therefore be enabled by a service owner (Opt-in).
💡Enabling this setting has no retroactive effect, meaning that only data after enabling this setting will get stored.

🤔What happens when I enable this?

☝ Task information / Session detail data is stored per service session on call termination (transfer by workflow or user).

The following is stored per session in both My Sessions and Historical Sessions
- Custom (user created) Parameters
- System Fields and Parameters (both “Custom” and "System" parameters like call id, service upn, etc.)
On historical (concluded) sessions within My Sessions
- ... the "Embedded Context widget" will resolve 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.

☝ Default "My Session Parameters" user data is not stored as it is 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 ⁽¹⁾ German Not used #1111	John Doe ⁽¹⁾ Not available (not stored) Not available (not stored) Not available (not stored)	John Doe ⁽¹⁾ German (from Service A) Male (from Service B) #3151 (from Service B)

⁽¹⁾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.

Luware Knowledge

Nimbus

Recording

Resource Library

Parameters

Adding Parameters