In Nimbus a task (call, chat, other interaction) is a data object, holding data fields such as a caller's phone number. Generally the call data object consists of read-only and writable fields, which can be extended by using your own Parameters as temporary placeholders - e.g. to hold data retrieved from an external CRM or lookup directory.
Common use cases involve:
- Steering Workflows based on a customer choice, stored in parameters.
- Showing incoming task / customer data to the Nimbus user via My Sessions or Attendant Console.
- Opening dynamic Conversation Context, e.g. a dynamic CRM or ticketing system URL for the receiving user to work with in parallel.
Lifetime and Handling
Please consider the following notes about data storage and retrieval from external systems:
DATA LIFECYCLE & PERSISTENCE
Parameters and fields within Nimbus have a life cycle during which the data can be accessed - usually during an ongoing session. At the end of each lifecycle the data will be disposed, meaning Nimbus does not store sensitive user data outside an ongoing Nimbus service/user session.
💡 You can enable a temporary storage of data via Extension Service Settings > “Store Conversation Context Data” option which stores the data for a retention period.
Learn more about stored 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.
DATA HANDLING & PROCESSING DELAYS
Nimbus cannot directly check and account for parameter manipulation delays. If a call workflow is progressing while an external system is busy, or a Power Automate flow is still running or erroneous, Parameters may not be updated for Nimbus in time. As a result, Nimbus sessions relying on updated information can lead to a failed workflow routing or lack UI information.
✅ Tip: In your Workflows you can use the “Wait for Parameter” activity to wait for a set period of time for a parameter to update before progressing.
Recommendations:
- Always ensure that your own parameters have a default value and that your workflows handle the “not recognized” paths accordingly to account for errors.
- We generally recommend to account for external system delays - e.g. by adding announcements to your workflows.
- Check your flow performance regularly (e.g. during high call volume hours) and test performance-affecting changes which involve further external systems.
Overview
Below is the comprehensive list of all parameters and related fields available in a Nimbus call data object:
Table Legend
As a lot of information is conveyed in the following table, the following abbreviations have been defined:
Type:
Lifecycle Scope:
|
Visibility checkboxes: ✅
|
Call Data
Call Data
Caller Data Fields | Type | Lifecycle Scope | Placeholder | UI Name | PA | RO | CCT | AC | CI | UI | Comments |
---|---|---|---|---|---|---|---|---|---|---|---|
CustomerFirstName | STR | Caller Session | $(Customer.FirstName) | Customer First Name | ✅ | - | ✅ | ✅ | ✅ | ✅ | - |
CustomerLastName | STR | Caller Session | $(Customer.LastName) | Customer Last Name | ✅ | - | ✅ | ✅ | ✅ | ✅ | - |
CustomerDisplayName | STR | Caller Session | $(Customer.DisplayName) | Customer Display Name | ✅ | - | ✅ | ✅ | ✅ | ✅ | - |
CustomerUpn | STR | Caller Session | $(Customer.Upn) | Customer UPN | ✅ | - | ✅ | ✅ | ✅ | ✅ | - |
CustomerImAddress | STR | Caller Session | $(Customer.ImAddress) | Customer IM Address | ✅ | - | ✅ | ✅ | ✅ | ✅ | - |
CustomerEmail | STR | Caller Session | $(Customer.Email) | Customer Email | ✅ | - | ✅ | ✅ | ✅ | ✅ | - |
CustomerCompany | STR | Caller Session | $(Customer.Company) | Customer Company | ✅ | - | ✅ | ✅ | ✅ | ✅ | - |
CustomerJobTitle | STR | Caller Session | $(Customer.JobTitle) | Customer Job Title | ✅ | - | ✅ | ✅ | ✅ | ✅ | - |
CustomerDepartment | STR | Caller Session | $(Customer.Department) | Customer Department | ✅ | - | ✅ | ✅ | ✅ | ✅ | - |
CustomerStreetAddress | STR | Caller Session | $(Customer.StreetAddress) | Customer Street Address | ✅ | - | ✅ | ✅ | ✅ | ✅ | Used to render a google maps location wherever caller information is shown. |
CustomerPostCode | STR | Caller Session | $(Customer.PostCode) | Customer Post Code | ✅ | - | ✅ | ✅ | ✅ | ✅ | Used to render a google maps location wherever caller information is shown. |
CustomerCity | STR | Caller Session | $(Customer.City) | Customer City | ✅ | - | ✅ | ✅ | ✅ | ✅ | Used to render a google maps location wherever caller information is shown. |
CustomerState | STR | Caller Session | $(Customer.State) | Customer State | ✅ | - | ✅ | ✅ | ✅ | ✅ | Used to render a google maps location wherever caller information is shown. |
CustomerCountry | STR | Caller Session | $(Customer.Country) | Customer Country | ✅ | - | ✅ | ✅ | ✅ | ✅ | Used to render a google maps location wherever caller information is shown. |
CustomerPrimaryTelNumber | STR | Caller Session | $(Customer .PrimaryTelNumber) |
Customer Primary Tel Number | ✅ | - | ✅ | ✅ | ✅ | ✅ | The phone number of the customer, without a leading "+" character. |
STR | Caller Session | $(Customer .+PrimaryTelNumber) |
Customer Primary + Tel Number | ✅ | - | ✅ | ✅ | ✅ | ✅ | The phone number of the customer, in full E.164 notation, including the leading "+" character. | |
Customer.CustomFields | OBJ | Caller Session | $(Customer.CustomFields .<Name>) |
Customer Custom Fields | ✅ | - | ✅ | ✅ | ✅ | ✅ |
💡 To select a the specific field in this data object, replace <Name> by a fieldname of your choice. Example: $(Customer.CustomFields.CRMId) |
Customer.TelNumbers | OBJ | Caller Session | $(Customer.TelNumbers .<Name>) |
Customer Tel Numbers | ✅ | - | ✅ | ✅ | ✅ | ✅ |
💡 To select a the specific field in this data object, replace <Name> by a fieldname of your choice. Example: $(Customer.TelNumbers.Mobile) or $(Customer.TelNumbers.Home) |
MicrosoftCallerId | STR | Caller Session | $(MicrosoftCallerId) | Microsoft Caller ID | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | Original caller ID sent by Microsoft Teams |
CallId | STR | Caller Session | $(CallId) | Call ID | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | |
CallChainId | STR | Caller Session | $(CallChainId) | Call Chain ID | ✅ | ✅ | - | - | - | ✅ | Call Chain ID from Microsoft Teams (secondary CallId) used to trigger Verba Recording |
CallerId | STR | Caller Session | $(Caller.Id) | Caller ID | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | Derived from the MicrosoftCallerId, if its value is a GUID instead of an E.164 phone number |
CallerUPN | STR | Caller Session | $(Caller.Upn) | Caller UPN | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | The User Principal Name of the caller- valid only if the call came from an internal Teams user |
CallerTelNumber | STR | Caller Session | $(Caller.TelNumber) | Caller Tel Number | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | The phone number of the caller, without the leading "+" character. Taken from the MicrosoftCallerId, if its value is an E.164 phone number |
STR | Caller Session | $(Caller.+TelNumber) | Caller + Tel Number | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | The phone number of the caller, including the leading "+" character. Taken from the MicrosoftCallerId, if its value is an E.164 phone number |
INC Parameter Size Limitations
Parameter Field Size Limitations
Please note both User Custom-created Parameters and Nimbus System Fields and Parameter fields underly size limitations. When exceeded, the Nimbus Power Automate Connector will return a 400 Bad Request.
Learn more…
Area | Field | Limitation |
---|---|---|
Task | TaskID | 64 characters |
Customer | Firstname | 64 characters |
Lastname | 64 characters | |
Displayname | 256 characters | |
Company | 64 characters | |
Department | 64 characters | |
Jobtitle | 128 characters | |
Streetaddress | 1024 characters | |
Postcode | 40 characters | |
City | 128 characters | |
Country | 128 characters | |
State | 128 characters | |
PrimaryTelNumber | 32 characters | |
Telnumbers | Telnumber Entry | not more than 10 |
name | 64 characters | |
value | 32 characters | |
UPN | 128 characters | |
IMAddress | 128 characters | |
128 characters | ||
customFields | CustomField Entry | Not more than 20 |
Name | 64 characters | |
value | 1024 characters | |
Parameters | customContextParameters | Not more than 50 |
name | 64 characters | |
value | 5120 | |
Distribution Policies | Preferred Users Entry | Not more than 10 |
UPN | 128 Characters | |
Outbound Call | SchedulerEntry | Extensions Tenant Settings > Max scheduled Outbound Tasks per service |
referenceId | 128 characters | |
destination: | 128 characters | |
distributionPriority | 16 characters | |
serviceUpn | 128 characters | |
customCallContextParameters | see above | |
customer | see above | |
External Task | externalTaskWriteDto |
Modalities Tenant Settings > Max concurrent External Tasks per service |
serviceUpn | 128 characters | |
customerIdentifier | 128 characters | |
customer | see above | |
distributionPriority | 16 characters | |
preferredUsers | see above | |
All IDs |
for example:
|
128 characters |
Virtual Assistants Service Settings | dataType | 64 characters |
System Data
System Data
Nimbus System Data | Type | Lifecycle Scope | Placeholder | UI Name | PA | RO | CCT | AC | CI | UI | Comments |
---|---|---|---|---|---|---|---|---|---|---|---|
Created | STR | Service Session | N/A | Not selectable / visible in UI | ✅ | ✅ | - | - | - | - | The time the session was created |
CustomerIdentifier | STR | Service Session | $(CustomerIdentifier) | Customer Identifier | ✅ | - | ✅ | - | - | ✅ |
System parameter, default "Anonymous". Can be manipulated via "AddExternalTask" Flow Action. 🔍 Field is set differently according to modality: Inbound AV/IM: MicrosoftCallerIdentifier Outbound AV: MicrosoftDestinationIdentifier ExternalTask: Customer.Identifier EmailTask: Customer.Email or O365UserId in case of an email from internal user |
EmailServiceMailboxUPN | STR | Service Session | N/A | Email Service Mailbox Upn | ✅ | ✅ | ✅ | ✅ | - | ✅ | Mailbox UPN of the mailbox assigned to the service Modality Settings . |
EmailSubject | STR | Service Session | N/A | Email Subject | ✅ | ✅ | ✅ | ✅ | - | ✅ | Mail subject |
EmailBodyUniqueRichText | STR | Service Session | N/A | Not selectable / visible in UI | ✅ | ✅ | - | - | - | - | Mail unique body. HTML in most cases. If the length exceeds allowed by MS Flow length, it is cut. |
EmailBodyUniquePlainText | STR | Service Session | N/A | Not selectable / visible in UI | ✅ | ✅ | - | - | - | - | Mail unique body. Plain text. If the length exceeds allowed by MS Flow length, it is cut. |
Event | STR | Flow Run | N/A | Not selectable / visible in UI | ✅ | ✅ | - | - | - | - | The session Event that occurred |
Id | STR | Service Session | N/A | Not selectable / visible in UI | ✅ | ✅ | - | - | - | - | The ID of the session |
InitialMessage | STR | Service Session | N/A | Initial Message | ✅ | ✅ | ✅ | ✅ | . | . | Usable in Service Call Templates / Direct Call Templates and IM Workflows for processing an incoming message sent by the user. |
IsAnonymous | BOL | Service Session | N/A | Not selectable / visible in UI | ✅ | ✅ | - | - | - | - | Is the caller anonymous? (True/False) |
LastConnectedUserId | STR | Service Session | N/A | Not selectable / visible in UI | ✅ | ✅ | - | - | - | - | The ID of the last connected user |
OutboundTaskId | STR | Outbound Task | N/A | Not selectable / visible in UI | ✅ | ✅ | - | - | - | - | ID when creating OutboundCalls. The OutboundTaskId is returned during GetOnUpdatedTasks and GetOnNewTasks Trigger Events. |
OutboundAttempt | INT | Service Session | N/A | Not selectable / visible in UI | ✅ | ✅ | - | - | - | - | Current attempt number of OutboundCalls. Increases with every attempt. |
RequestId | STR | Flow Run | N/A | Not selectable / visible in UI | ✅ | ✅ | - | - | - | - |
Request ID to use to Update Tasks. ☝ Known Limitations: Flow "RequestID" When a new External Task (ET) is created via Power Automate Flow Action, the "RequestId" value will not be returned. This means that you can't create and update an ET within the same flow. → You need configure an additional flow – based on one of the Nimbus Trigger Events – and update the ET via "UpdateTask" action. |
ServiceLineTelNumber | STR | Service Session | $(ServiceLine .TelNumber) |
Service Line Tel Number | ✅ | ✅ | ✅ | ✅ | - | ✅ | - |
STR | Service Session | $(ServiceLine .+TelNumber) |
Service Line + Tel Number | ✅ | ✅ | ✅ | ✅ | - | ✅ | - | |
ServiceLineDisplayName | STR | Service Session | $(ServiceLine .DisplayName) |
Service Line Display Name | ✅ | ✅ | ✅ | ✅ | - | ✅ | - |
ServiceLineUPN | STR | Service Session | $(ServiceLine.Upn) | Service Line Upn | ✅ | ✅ | ✅ | ✅ | - | ✅ | - |
TeamName | STR | Service Session | $(TeamName) | Team Name | ✅ | ✅ | ✅ | ✅ | - | ✅ | - |
TeamId | STR | Service Session | $(TeamId) | Team ID | ✅ | ✅ | ✅ | ✅ | - | ✅ | - |
TeamDescription | STR | Service Session | $(TeamDescription) | Team Description | ✅ | ✅ | ✅ | ✅ | - | ✅ | - |
Terminated | STR | Service Session | N/A | Not selectable / visible in UI | ✅ | ✅ | - | - | - | - | The time the session was terminated |
Type | STR | Service Session | N/A | Not selectable / visible in UI | ✅ | ✅ | - | - | - | - | Session type |
INC Parameter Size Limitations
Parameter Field Size Limitations
Please note both User Custom-created Parameters and Nimbus System Fields and Parameter fields underly size limitations. When exceeded, the Nimbus Power Automate Connector will return a 400 Bad Request.
Learn more…
Area | Field | Limitation |
---|---|---|
Task | TaskID | 64 characters |
Customer | Firstname | 64 characters |
Lastname | 64 characters | |
Displayname | 256 characters | |
Company | 64 characters | |
Department | 64 characters | |
Jobtitle | 128 characters | |
Streetaddress | 1024 characters | |
Postcode | 40 characters | |
City | 128 characters | |
Country | 128 characters | |
State | 128 characters | |
PrimaryTelNumber | 32 characters | |
Telnumbers | Telnumber Entry | not more than 10 |
name | 64 characters | |
value | 32 characters | |
UPN | 128 characters | |
IMAddress | 128 characters | |
128 characters | ||
customFields | CustomField Entry | Not more than 20 |
Name | 64 characters | |
value | 1024 characters | |
Parameters | customContextParameters | Not more than 50 |
name | 64 characters | |
value | 5120 | |
Distribution Policies | Preferred Users Entry | Not more than 10 |
UPN | 128 Characters | |
Outbound Call | SchedulerEntry | Extensions Tenant Settings > Max scheduled Outbound Tasks per service |
referenceId | 128 characters | |
destination: | 128 characters | |
distributionPriority | 16 characters | |
serviceUpn | 128 characters | |
customCallContextParameters | see above | |
customer | see above | |
External Task | externalTaskWriteDto |
Modalities Tenant Settings > Max concurrent External Tasks per service |
serviceUpn | 128 characters | |
customerIdentifier | 128 characters | |
customer | see above | |
distributionPriority | 16 characters | |
preferredUsers | see above | |
All IDs |
for example:
|
128 characters |
Virtual Assistants Service Settings | dataType | 64 characters |
Custom Context Parameter
Custom Context Data
In its default configuration there are no custom predefined parameters in Nimbus. In case you need to store and handle your own information you can create these custom Parameters in the in the Configuration section of Nimbus.
Custom Context Data | Type | Lifecycle Scope | Placeholder | UI Name | PA | RO | CCT | AC | CI | UI | Comments |
---|---|---|---|---|---|---|---|---|---|---|---|
Custom ContextParameters |
OBJ | Caller Session |
$(CustomContextParameters Example: $(CustomContextParameters |
Custom Context Parameters | ✅ | ✅ | - | ✅ | - | ✅ |
🔎 Parameters can be defined as a preselection in Configuration > Parameters 💡 To select a the specific field in this data object, replace <Name> by a fieldname of your choice. 👆 In Microsoft Flow these names need to be entered manually! Example: |
UpdatedParameterName | STR | Flow Run | Name portion of "CustomContextParameters" | UpdatedParameter Name | ✅ | ✅ | - | ✅ | - | ✅ |
🔎 Used to store the "name / value" portion of a CustomContextParameter (for easier selection within a Flow) → See Parameters for examples of use. |
UpdatedParameterValue | STR | Flow Run | Value portion of "CustomContextParameters" | UpdatedParameter Value | ✅ | ✅ | - | ✅ | - | ✅ |
INC Parameter Size Limitations
Parameter Field Size Limitations
Please note both User Custom-created Parameters and Nimbus System Fields and Parameter fields underly size limitations. When exceeded, the Nimbus Power Automate Connector will return a 400 Bad Request.
Learn more…
Area | Field | Limitation |
---|---|---|
Task | TaskID | 64 characters |
Customer | Firstname | 64 characters |
Lastname | 64 characters | |
Displayname | 256 characters | |
Company | 64 characters | |
Department | 64 characters | |
Jobtitle | 128 characters | |
Streetaddress | 1024 characters | |
Postcode | 40 characters | |
City | 128 characters | |
Country | 128 characters | |
State | 128 characters | |
PrimaryTelNumber | 32 characters | |
Telnumbers | Telnumber Entry | not more than 10 |
name | 64 characters | |
value | 32 characters | |
UPN | 128 characters | |
IMAddress | 128 characters | |
128 characters | ||
customFields | CustomField Entry | Not more than 20 |
Name | 64 characters | |
value | 1024 characters | |
Parameters | customContextParameters | Not more than 50 |
name | 64 characters | |
value | 5120 | |
Distribution Policies | Preferred Users Entry | Not more than 10 |
UPN | 128 Characters | |
Outbound Call | SchedulerEntry | Extensions Tenant Settings > Max scheduled Outbound Tasks per service |
referenceId | 128 characters | |
destination: | 128 characters | |
distributionPriority | 16 characters | |
serviceUpn | 128 characters | |
customCallContextParameters | see above | |
customer | see above | |
External Task | externalTaskWriteDto |
Modalities Tenant Settings > Max concurrent External Tasks per service |
serviceUpn | 128 characters | |
customerIdentifier | 128 characters | |
customer | see above | |
distributionPriority | 16 characters | |
preferredUsers | see above | |
All IDs |
for example:
|
128 characters |
Virtual Assistants Service Settings | dataType | 64 characters |
🔍 Usage: Custom Context Parameters can be used in the following areas:
Area |
Usage within |
---|---|
Workflows |
|
Nimbus Power Automate Connector |
Flow Actions > Action "UpdateTask"
|
Conversation Context |
As part of a context URL:
|
Extension Service Settings |
My Sessions UI customization:
☝ A “Store Conversation Context Data” option determines parameter storage lifetime. |
Address Book Fields
✅ Precondition: Only Tenant Administrators have the possibility to see the available Address Book of this tenant in the flow dropdowns.
Address Book Fields
By using the "Address Book" Flow Action Address Book fields can be accessed and/or manipulated:
Name | Type | Description |
---|---|---|
ExternalId | string | ID the system where the entry was imported from. |
FirstName | string | First Name |
LastName | string | Last / Family Name |
DisplayName | string | Firstname / Last name combination |
Initials | string | Initials (e.g. "JK") |
Company | string | Company |
Department | string | Department |
JobTitle | string | Job Title |
ImAddresses | string | IM SIP Address |
EmailAddresses | string | Email Address |
BusinessPhones | string | Business Phone |
MobilePhones | string | Mobile Phone |
HomePhones | string | Home Phone |
UserPrincipleName | string | Consists of: user name (logon name), separator (the @ symbol), and domain name (UPN suffix) |
Addresses | string | Street Address |
Street | string | Street and No. |
City | string | Code and City |
Country | string | Country of Origin |
CustomFields | string | Custom field array of name / value pairs. |
🔍 Address book "Contact details" - excluding empty fields - will be provided in Attendant Console as a tooltip provided within the "Contact Search".
INC Address Book Limitations
Address Book Field Size Limitations
Please note that Address Books fields underly size limitations. When exceeded, the Nimbus Power Automate Connector will return a 400 Bad Request.
Learn more…
Area | Field | Limitation |
---|---|---|
Contact | ExternalId | 128 characters |
Firstname | 64 characters | |
Lastname | 64 characters | |
Displayname | 256 characters | |
Initials | 16 characters | |
Company | 64 characters | |
Department | 64 characters | |
JobTitle | 128 characters | |
UPN | 128 characters | |
IMAddresses | IMAddress |
Maximum of 10 addresses 128 characters per address |
Emails | EmailAddresses |
Maximum of 10 addresses 128 characters per address |
PhoneNumbers |
Businessphones Mobilephones Homephones |
Maximum of 10 phone numbers (per type). 32 characters per phone number |
Address | Adresses | Not more than 10 addresses |
Street: | 1024 characters | |
City: | 128 characters | |
Country | 128 characters | |
State | 128 characters | |
Postal code | 40 characters | |
CustomFields | Field array of name / value pairs. | Maximum of 20 custom fields |
name | 64 characters | |
value | 1024 characters |
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.