System Fields and Parameters

Storing and updating context during active sessions

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:

Historical storage of Context Data
 

☝ 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).

☝ 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)

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

  • STR = string
  • OBJ = object
  • BOL = boolean
  • INT = integer

Lifecycle Scope:

  • Service Session: The parameter only exists within the same service session. In workflow terms: within one workflow until transfer or disconnect.
  • Caller Session: The parameter persists throughout the whole customer session.
  • Flow Run: The parameter only exist in the Power Automate flow run and is discarded once the flow is complete.

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
  Email 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: 

  • AddressbookId:
  • SchedulerEntryId
  • serviceSessionId
  • externalTaskId
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
  Email 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: 

  • AddressbookId:
  • SchedulerEntryId
  • serviceSessionId
  • externalTaskId
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   
.Name>)

Example:

$(CustomContextParameters   
.CrmUrl)

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:   
$(CustomContextParameters   
.CrmUrl)

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
  Email 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: 

  • AddressbookId:
  • SchedulerEntryId
  • serviceSessionId
  • externalTaskId
128 characters
Virtual Assistants Service Settings  dataType 64 characters
 
 
 

🔍 Usage: Custom Context Parameters can be used in the following areas:

Area
Usage within
Workflows 

Workflow Activities

  • "Voice Message" 
  • "Input customer" 
  • "Collect Information" 
  • “Check Parameter”
  • “Wait for Parameter”
Nimbus Power Automate Connector 

Flow Actions > Action "UpdateTask"

  • CustomContextParameter.<ID>
Conversation Context 

As part of a context URL:

  • $(CustomContextParameters.<ID>)
Extension Service Settings 

My Sessions UI customization:

  • "Session Details" widget

 ☝ 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:    
+12345678910

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

Address Book

 (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:

 
 

Table of Contents