Bolt Data Connect – Help Docs

Docs: App Tour

Mon, 01 Jan 0001 00:00:00 +0000

Launching the App

Once you install the Salesforce App, you"ll find the new Bolt Data Connect App in the Salesforce App Launcher.

App Launcher

Note

If you don’t see what you"re looking for, use the “Search apps or items..” search bar provided in the App Launcher to search for “Bolt Data Connect”

App Launcher Search

IoT Dashboard

The IoT Dashboard is a Salesforce Dashboard & Reports giving you a view of all of your “Things” connected to Bolt Data Connect and the Thing Types, Status, Alert History and Sensor Data available in Salesforce.

IoT Dashboard

IoT Console

The IoT Console is the centralized dashboard for viewing all IoT Things within an Org.

IoT Console

The Navigation Panel provides multiple ways to slice your Things. Here you can find all Things by:

Category: A completely customizable tree, grouping Things by whichever fields your Admin configures. Check out Thing Object Settings for more details on how to configure this.
Status: Things change status based on the rules established for each Thing-Type
Search: If you know the exact asset you"re looking for.

Navigation Panels

Views

The View Panel shows you Things that match criteria specified in the Navigation Panel. There are currently two Views available: a Map View and a Data View. The Map View shows Things as pins on a global map, while the Data View shows Things in a tabular view.

View - Map

Additionally, in the Data View, you can view the History for any device by selecting the down arrow on any row.

View - Data Table

In the Data View you have the ability to view the sensor chart, sensor data-table, filter and save new sensor snapshots.

Note

Historical data is not stored in Salesforce, but rather in the IoT Cloud, and is only fetched here for troubleshooting and diagnostics. This helps reduce the load on your Salesforce Data Limits.

IoT Setup

For your Salesforce Org Admins, the Bolt Data Connect App provides an IoT Setup page to configure how the IoT Cloud integrates with your Salesforce Org. Here you can completely control the behavior of the Cloud and Edge Processing, as well as the Salesforce automation and integrations.

IoT Setup

Docs: App Tour

Mon, 01 Jan 0001 00:00:00 +0000

Launching the App

Once you install the ServiceNow App, you"ll find the new Bolt Data Connect App Modules in the ServiceNow All Menu.

App Modules

Connected Assets Workspace

The Connected Assets Workspace is a ServiceNow Now Experience Workspace. The home page displays a Dashboard containing Visualizations which gives you a view of all of your “Things” connected to Bolt Data Connect and the Thing Types, Status, Alert History and Sensor Data available in Salesforce.

IoT Dashboard

IoT Console

The IoT Console is the centralized dashboard for viewing all Connected Assets within an Instance.

IoT Console Map

IoT Console Cards

IoT Setup

For your ServiceNow Instance Admins, the Bolt Data Connect App provides an IoT Setup Module to configure how the IoT Cloud integrates with your ServiceNow Instance. Here you can completely control the behavior of the Cloud and Edge Processing, as well as the ServiceNow automation and integrations.

IoT Setup Module

Docs: Servitization Testing

Fri, 05 May 2023 00:00:00 +0000

Servitization Testing is typically a challenge due to long testing cycles (driven by Monthly / Quarterly output), complicated testing procedures, and error-prone manual entry of sensor / calculated values.

Testing Console

On the Servitization Plan, the Console tab provides a Testing Console to ease the testing effort, by automating the required steps and simplifying the process.

Servitization Test Console

The following steps can be executed in a single click, and just a few minutes:

Post Device Values: By sending an IoT Command to the Gateway / Connector, the IoT Values from a specific Date/Time can be retrieved and reprocessed by the IoT Cloud. Simply select the dates and Covered Things desired. This allows the tester to “roll the clock back” and control the test without manual data entry (and possible human error).
Run Sensor Data Job: Executes the Sensor Data Sync Job to download Sensor Data from the IoT Cloud into Salesforce, for the specific Covered Things selected. (See the IoT Setup > Sensor Data settings for details)
Run Servitization Job: Executes the Servitization Job for this specific Plan and Target Date. (Similar to clicking the Execute button on the Plan)

IoT Command Template: Servitization Target Date

The IoT Command Template named Servitization Target Date will be sent for each Covered Thing in Step 1 above. This template needs to be customized with specific values and the appropriate connector id.

Topic: Update with the appropriate MQTT Topic for the Connector in use
Body: Update with any custom fields / values needed by the Connector

Servitization Target Date Command Template

Docs: App Connectivity

Mon, 01 Jan 0001 00:00:00 +0000

First, we’ll need to establish the connection between your Salesforce Org and the IoT Cloud infrastructure. Once that connection is established, we can configure Salesforce Object Customization, Salesforce Process Customization, and Thing-Type Customization. Then, we’ll create a new Thing and demonstrate connectivity. Let’s get Things set-up!

In order for the Bolt Data Connect Salesforce App to communicate with the IoT infrastructure, we need to authorize Salesforce to access the IoT Cloud, and we need authorize the IoT Cloud to access Salesforce.

Authorize Salesforce to access the IoT Cloud

First, your Bolt Data Connect support representative should provide you with an API Token, an Access Key, and a Secret Key. Keep this information safe. It’s essentially your username and password to your IoT Cloud.

Let us know

Should you ever learn or suspect these Keys have been compromised, please rotate your keys — twice — as soon as possible, and notify your Bolt Data Connect representative.

From the Bolt Data Connect App (if you’re not already there, follow the Launching the App section in the App Tour), go to the IoT Setup tab.
Select Global Settings.
In the IoT API Token field enter the API Token you received in Step 1.
Select the IoT Cloud API link next to API Named Credential.
1. Select Edit.
2. In the AWS Access Key ID field, enter the Access Key received in Step 1.
3. Next to AWS Secret Access Key field, enter the Secret Key received in Step 1.
4. You shouldn’t need to modify any other settings here. Click Save and close the tab (if it opened in a new tab).

Authorize the IoT Cloud to access your Salesforce Org

In order for the IoT Cloud to send Alerts to your Salesforce Org, you must Authorize the app to access the Salesforce APIs associated with your Org.

From the Bolt Data Connect App (if you’re not already there, follow the Launching the App section in the App Tour), go to the IoT Setup tab.
Select Global Settings.
Next to the Connected Application label, select Authorize.

Authorize the Connected Application

You’ll be redirected to a Salesforce Authorization screen. Select Allow.

Heads Up

Verify the URL in this window is accurate. You must be logged in as a User of the Org in which you wish to authorize the IoT Cloud integrations (this is the User the IoT Cloud will use to send Alerts and trigger platform events). If you need to switch to another User, you can select the “Not you?” link to be redirected to (login.salesforce.com)[https://login.salesforce.com] to log-in and authorize as a different User within your Org.

Allow the IoT Cloud to access your Org

After selecting Allow, the status of the authorization will be displayed.
When successful, the authorization status message window will close automatically (or you can close it manually if you chose). In the unlikely event you encounter an error during authorization, please let us know as soon as practical!

Authorization success message

Note

Bolt Data Connect does not collect any data from you or your Org; this authorization only provides the IoT Cloud with the ability to send alerts to your Org. The IoT Cloud is never given your login credentials.

That’s it! This should only be required once, but should you ever need to re-establish this authorization, you can repeat these steps at any time.
To revoke authorization at any time, you can follow these steps:
1. Select Settings (Salesforce Settings Gear).
2. Select Users, then Users and find the User you used to Authorize.
3. Scrolling down, you should find the “OAuth Connected Apps” section where you can select Revoke to revoke access to the Connected App.
4. You can re-authorize the IoT Cloud at any time by following the steps above.
You can check which Saleforce User is currently authorized by the IoT Cloud at any time.
1. Navigate to the IoT Admin Page, then select Global Settings.
2. The User should be displayed next to the Connected Application label:
Authorization check

Rotating Bolt Data Connect Access Keys

The Bolt Data Connect Access Keys can be rotated at any time. This helps limit any unintended access to your data. We recommend that you refresh Access Keys at least every 45 days, but the more frequent, the better.

From the Bolt Data Connect App (if you’re not already there, follow the Launching the App section in the App Tour), go to the IoT Setup tab.
Select Global Settings.
You’ll need to have the Named Credential open in a separate window/tab:
1. Select the IoT Cloud API link (should open in a new tab; if not, keep this tab/window open to the Named Credential and open a new tab to the IoT Setup tab, Global Settings).
2. Select Edit.
3. In the next step you’ll be editing the following fields: AWS Access Key ID and AWS Secret Access Key.
Named credential fields
Once the Named Credential tab/window is staged, back on the IoT Admin page, select Rotate Keys.
New Keys should appear under the Rotate Keys button with a copy link next to each.

New keys

Select “Copy” next to AWS Access Key ID, and paste into the respective field on the Named Credential.
Repeat for AWS Secret Access Key.
Select Save on the Named Credential and close that tab/window.
To clear the keys from the Global Settings screen, return to the IoT Setup tab.
To test the new keys, return to the Global Settings screen from the IoT Setup tab (which automatically checks who’s authorized) or visit the IoT Console and search for a Thing.

IoT Connector API

For customers with their own IoT Cloud, we’ve fully exposed the IoT Cloud Connector API to allow you to use the Bolt Data Connect Salesforce App with your own IoT Cloud by following a few simple steps. (See below)

IoT Cloud Connector

Call the /IoTAlert Web Service from your IoT Cloud
Implement the IoT Connector Apex class [SPKI.IoT_Connector_API] to call your IoT Cloud’s exposed APIs

IoT Cloud Connector API

Docs: App Connectivity

Mon, 01 Jan 0001 00:00:00 +0000

First, we’ll need to establish the connection between your ServiceNow Instance and the IoT Cloud infrastructure.

In order for the Bolt Data Connect ServiceNow App to communicate with the IoT infrastructure, we need to authorize the ServiceNow Instance to access the IoT Cloud, and we need authorize the IoT Cloud to access Salesforce.

Authorize the ServiceNow Instance to access the IoT Cloud

First, your Bolt Data Connect support representative should provide you with an API Token, an Access Key, and a Secret Key. Keep this information safe. It’s essentially your username and password to your IoT Cloud.

Let us know

Should you ever learn or suspect these Keys have been compromised, please notify your Bolt Data Connect representative.

From the ServiceNow All Menu -> Bolt Data Connect -> IoT Setup module, select Settings.
In the Instance-Specific API Token field enter the API Token you received in Step 1.
Select the IoT Cloud link next to Credential Alias.
1. Select the credential that shows up in the related list towards the bottom of the page.
2. In the AWS Access Key ID field, enter the Access Key received in Step 1.
3. In the AWS Secret Access Key field, enter the Secret Key received in Step 1.
4. You shouldn’t need to modify any other settings here. Click Update and close the tab (if it opened in a new tab).

Authorize the IoT Cloud to access your ServiceNow Instance

In order for the IoT Cloud to send Alerts to your ServiceNow Instance, you must Authorize the app to access the ServiceNow APIs associated with your instance.

From the ServiceNow All Menu -> Bolt Data Connect -> IoT Setup module, select Settings.
Below the Connected Application label, select Authorize.

Authorize the Connected Application

You’ll be redirected to a ServiceNow Authorization_ screen. Select Allow.

Heads Up

Verify the URL in this window is accurate. You must be logged in as a User of the Instance in which you wish to authorize the IoT Cloud integrations (this is the User the IoT Cloud will use to send Alerts and trigger platform events). If you need to switch to another User, you can select the “Not you?” link to be redirected to your Instance’s login page to log-in and authorize as a different User within your Instance.

Allow the IoT Cloud to access your Org

After selecting Allow, refresh the page. The status of the authorization will be displayed.
When successful, the authorization status message window will close automatically (or you can close it manually if you chose). In the unlikely event you encounter an error during authorization, please let us know as soon as practical!

Authorization success message

Note

Bolt Data Connect does not collect any data from you or your Instance; this authorization only provides the IoT Cloud with the ability to send alerts to your Instance. The IoT Cloud is never given your login credentials.

That’s it! This should only be required once, but should you ever need to re-establish this authorization, you can repeat these steps at any time.
To revoke authorization at any time, you can follow these steps:
1. Select All (ServiceNow All Modules)
2. Search for System OAuth and select Manage Tokens.
3. You should find up to three tokens with the name IoT Cloud. You can either delete these records or select them and click Revoke Access.
4. You can re-authorize the IoT Cloud at any time by following the steps above.
You can check which ServiceNow User is currently authorized by the IoT Cloud at any time.
1. Navigate to the Settings module found under All -> Bolt Data Connect -> IoT Setup -> Settings.
2. The User should be displayed next to the Connected Application label:
Authorization check

Docs: Licensing

Mon, 01 Jan 0001 00:00:00 +0000

View Licenses

From the Global Settings page, you can easiliy view the Bolt Data Connect licensing across all of your orgs (Dev, Test, Production, etc.) and all of the Application Layers (Salesforce, IoT Cloud and Edge Gateway).

View Licenses

Salesforce Licenses

Standard Licenses: The number of Standard Bolt Data Connect Salesforce User licenses used / total available.
Community Licenses: The number of Community (Experience Cloud) Bolt Data Connect Salesforce User licenses used / total available.
Last License Check: The most recent date of synchronizing the Licenses with Salesforce.
License Status: The status of the License from Salesforce App Exchange.
License Expiration: The date of the License Expiration from Salesforce App Exchange.

Cloud Licenses

Organization: The parent / local IoT Cloud accounts connected to this org
License Usage: A calculation of the total percentage of device licenses used across all orgs
Thing Message Rates: A list of licensed message rates along with the purchased and used count of each
Hardware Device Types: A list of licensed devices types along with the purchased and used count of each

License Flexibility

As Thing Type “Message Rate” definitions are changed, licensing is evaluated and updated. We’ve implemented a flexible license usage policy, allowing you to use any Message Rate below or equal to the purchased rate.

License Alarms

License Alarms can now be configured and automatically created into Salesforce so that administrators can monitor and automate actions on both Salesforce App and Device Licenses.

To view the License Logs and Alarms, create a Report:

Report Type: IoT Admin Logs
Filters:
- Show Me: All IoT Admin Logs
- Log Type: “Licensing”

You will find 2 records for each Licensing event, with the following Job / Record Id values:

APP_LICENSES : Lists the results of the Salesforce App Licensing check
DEVICE_LICENSES : Lists the results of the IoT Cloud Device Licensing check

License Alarms

Each of the above records will have one of the following Job Status values:

Success : Indicates that the license check was successful and no alarms were created.
Warning : Indicates that one of the following alarms was included:
- Less than 30 days remaining on Salesforce Licenses
- Salesforce License Usage is above 80% threshold
- Device License Usage is above 90% threshold
- No Device Licenses found
Error : Indicates that one of the following alarm errors was encountered:
- Salesforce License Usage Exceeded
- Could not load Managed Package licensing data

Docs: Licensing

Mon, 01 Jan 0001 00:00:00 +0000

View Licenses

From the Settings module, you can easiliy view the Bolt Data Connect licensing across all of your Instances (Dev, Test, Production, etc.) and all of the Application Layers (ServiceNow, IoT Cloud and Edge Gateway).

View Licenses

ServiceNow Licenses

Standard Licenses: The number of Standard Bolt Data Connect IoT User licenses used.
Admin Licenses: The number of Admin Bolt Data Connect IoT User licenses used.
Portal Licenses: The number of Portal Bolt Data Connect ServiceNow User licenses used.
Last License Check: The most recent date of synchronizing the Licenses with ServiceNow.
License Status: The status of the License from ServiceNow.
License Expiration: The date of the License Expiration from ServiceNow.

IoT Cloud Licenses

Organization: The parent / local IoT Cloud accounts connected to this Instance
License Usage: A calculation of the total percentage of device licenses used across all Instances
Thing Message Rates: A list of licensed message rates along with the purchased and used count of each
Hardware Device Types: A list of licensed devices types along with the purchased and used count of each

License Flexibility

Docs: Thing Object

Mon, 01 Jan 0001 00:00:00 +0000

From the Bolt Data Connect App (if you’re not already there, follow the Launching the App section in the App Tour), go to the IoT Setup tab.
Select Global Settings.
In the Thing Object Settings section of the Global Settings page, select the Salesforce Object in the Thing Object field.

Global Settings - Thing Object Settings

Field Definitions

Once you select an Object you can decide which Salesforce fields to bind to the following:

Thing Label: This field is used as the label in the IoT Console Views.
Thing External ID Field: This field is used as the primary key for data operations on a Thing (it’s how the data is indexed and must be unique within your Org).

Heads up

This field is the most important, as it allows your Thing’s data to be organized and accessed properly. Without this field, your Things’ data will just exist in the IoT Cloud and will be inaccessible from Salesforce.

Thing Status Field: This field is used in the IoT Console Navigation Pane and IoT Console Views.
Thing Type: This field is used as the identifier for which Thing-Type to assume for the given Thing. If a Thing has an undefined Thing Type, every message will be sent to the Cloud, unaggregated, and no Alerts will be provided (other than the built-in Offline Alert). For cost management purposes, it is highly recommended, that every Thing be assigned a Thing Type.
Thing Gateway: This field is used to determine which gateway will receive and manage your Things data. Without this field, your Thing’s data will not be aggregated or stored (i.e. your Thing won’t have anyone to talk to and its data will be lost). Must be a Lookup(IoT Gateway) field.
Context Data Field: This behind the scenes field will track the status of the context data syncing. Must be a Long Text Area field.
Last Alert Response Field: This behind the scenes field will track the most recent Alert Response and it’s results. Must be a Text field.
Thing Latitude/Longitude Fields: These fields are used to plot each Thing on the Map View in the IoT Console. Must be either two separate numeric fields, or a single Geo-Location field.
Category Labels/Fields: These fields determine the top-level navigation nodes in the IoT Console Navigation Pane Category Mode.
Sub-Category Fields: These fields determine the second-level navigation node in the IoT Console Navigation Pane Category Mode.

Docs: System Settings

Mon, 01 Jan 0001 00:00:00 +0000

Error Handling

From the Global Settings page, scroll to the section labeled “System Settings”, to control how the background jobs will handle any unexpected errors. There are currently two settings available:

Log Thing Errors to Chatter
Log Servitization Errors to Chatter

Error Handling

These settings, when enabled, will log any errors from background jobs to the Chatter Feed of the appropriate record. For Thing Errors they will be attached to the Asset, or your custom Thing Object if configured. For Servitization Errors they will be attached to the Servitization Plan.

Alternatively, if either these fields are NOT enabled the default behavior is to create “IoT Admin Log” records. This Custom Object can easily be accessed with Reports or as an Object Tab with List Views.

Chatter

If either of the above values are enabled, remember to also Enable the Feed Tracking of the corresponding Object (e.g. Servitization Plan, Asset, etc.) as seen in the following Setup screen.

Feed Tracking

Platform Event Handling

From the Global Settings page, scroll to the section labeled “System Settings”, to control how the Platform Events received from the IoT Cloud will be handled.

System Settings

By enabling the field “Disable Platform Event Triggers”, the managed Apex Triggers will no longer process the Platform Events. Instead, we’ve provided the following Platform Event Triggered Flows we recommend you activate:

Platform Event Triggered Flows

IMPORTANT

The reason for choosing to activate the Flows instead of the Apex Triggers is to change the User that will run the automation including:

IoT Alert History record creation
IoT Alert Responses
IoT Downtime record creation

The Apex Triggers are run as the “Automated Process” user whereas the Flows will run as the user configured in the Global Settings App-Connectivity section.

Docs: Thing Type Editing

Mon, 01 Jan 0001 00:00:00 +0000

Thing-Types define the configuration for Edge Processing.

Top Level Configuration

Label: The label to use for the Thing-Type specification.
Is Active: If a Thing’s Thing-Type is not active (i.e. this option is deselected), the Thing’s data will not be aggregated and every message will be forwarded from the Gateway to the Cloud. It is not recommended to deactivate a Thing-Type that is assigned to Things, except for brief troubleshooting; otherwise, it could potentially result in higher costs and missed Alerts.
Sample Message: Used to auto-populate the Sensors section of the Thing-Type Specification.
Aggregate Type: Determines when to send the aggregated messages. It can be configured to “None”, “Seconds”, or “Count”.

None: Forward every message received from the device to the cloud.
Seconds: Aggregate the last N seconds of Thing data, where N is defined by the Aggregate Interval field.
Count: Aggregate the last N messages from a Thing, where N is defined by the Aggregate Interval field.

Aggregate Interval: Used in conjunction with the Aggregate Type field to determine the frequency of aggregation performed on the Gateway.
Offline Timeout (Seconds): Used to determine if a Thing is offline. If a device has not communicated in the time specified in this field, then an Offline Alert is sent to Salesforce.

Digital Twin Children

See the Digital Twins page for details on configuring this section.

Sensors

This section defines all the Sensors for the Thing-Type. Note if you have a sample message in JSON format, you can paste the message in the Sample Message field and select Parse to auto-fill the Sensors section.

Label: The display name of the sensor data on plots.
Sensor Name: The name of the field in the actual Thing’s data message.

Example

Sensor Name = sensorABC, expects a field like {... "sensorABC": 123, ...} to be in the data message from the Thing.

Data Type: Specifies the type of data expected from each Sensor.
Aggregate Function: Determines how the data is aggregated in the Gateway.

NONE: Use the last received value as the value for the Sensor for Calculations, Alerts, and Cloud updates.
SUM: Sum all values received during the Aggregate Interval as the value for the Sensor for Calculations, Alerts, and Cloud updates.
AVG: Average all values received during the Aggregate Interval as the value for the Sensor for Calculations, Alerts, and Cloud updates.
MIN: Use the minimum of all values received during the Aggregate Interval as the value for the Sensor for Calculations, Alerts, and Cloud updates.
MAX: Use the maximum of all values received during the Aggregate Interval as the value for the Sensor for Calculations, Alerts, and Cloud updates.

Sensor Settings

Include Undefined Sensors: When not selected any unrecognized sensor value(s) will be trimmed from the messages before processing
Enable Sensor Type Conversion: When selected the raw sensor values will be convereted into the Data Types specified below

Context Fields

Context Fields are configured in the Context Data Setup Page.

ML Models

This section defines all the ML Models available on a Gateway. These Models have been developed by a Data Scientist and uploaded to the BDC IoT Cloud. NOTE: This section is only available on Gateway Thing Types.

See Machine Learning for more information.

Label: The label to use for the Calculated Field.
Model Name: The unique name of the model.
Input Features: The features required by this model. These will be mapped in the ML Inferences.
Model Parameters: Configuration values for the model itself.

ML Models

ML Inferences

This section defines all the ML Inference Fields for a Thing-Type. Each of these represent a result of executing an ML Model with a set of input values from IoT Sensors.

Label: The label to use for the ML Inference field.
Name: The name of the ML Inference field. It’s also the name referenced by other Calculations and Alerts.
Model: The ML Model (defined on the corresponding Gateway Thing Type) that will be executed.
Data Type: Determines the assumed data type for the result of the Calculation.
Formula: The mapping of Model Input Features to IoT Sensor values.

ML Inferences

Calculated Fields

This section defines all the Calculated Fields for a Thing-Type. All Sensor data is aggregated prior to computing the Calculated Fields. It can be assumed that all Sensor data is up-to-date in conformance with the aggregation settings defined by each Sensor.

Label: The label to use for the Calculated Field.
Field Name: The name of the field when this calculation is sent to the Cloud. It’s also the name referenced by other Calculations and Alerts.

Example

Field Name = calcABC results in {... "calcABC": 123, ...}, when data is sent to the Cloud and referenced as calculation.calcABC in other Calculations and Alerts.

Data Type: Determines the assumed data type for the result of the Calculation.
Formula: The actual formula to evaluate. The formula should be any Javascript statement that returns an assignable value. The formula can use any Sensor, Calculated Field, or Context Field in the computation. Sensor values are available in the sensor namespace (e.g. sensor.sensorABC), other Calculated Fields are available in the calculation namespace (e.g. calculation.calcABC), and Context Fields are available in the context namespace (e.g. context.contextABC).

Alert Conditions

This section defines all the Alert Conditions for a Thing-Type. Alerts are a special subset of Calculated Fields. Alerts are computed after all Calculated Fields have been computed, so it can be assumed that all Calculated Fields are using the most recent data. The result of the Alert calculation should be a boolean value, True if an Alert should be sent to Salesforce, False otherwise.

Label: The label to use for the Alert Condition.
Condition Name: The name of the field when this alert is sent to the Cloud.

Example

Condition Name = alertABC results in {... "alertABC": 123, ...}, when data is sent to the Cloud.

Alert Type: Determines the type of Alert sent to Salesforce. Each Alert sent to Salesforce will include this Alert Type, which can be used in your Processes to take actions (like update the IoT Thing Status for a given Thing).
Alert Interval / Units: Determines how often this Alert is re-broadcasted. If the Alert condition has persisted longer than the amount of time specified by this field, the Alert will be sent to Salesforce again, to retrigger any automated processes. It is recommended to keep the Alert Interval at rather large values to avoid retriggering your processes.
Impacts Uptime: When enabled, this Alert Type will impact Uptime calculations for “Downtime Periods” and “Servitization”
Formula: The actual formula to evaluate. The formula should be a Javascript statement, and can use any Sensor or Calculated Field in the calculation. The formula should result in a boolean value; It will be evaluated as if it’s boolean — i.e. if the value is “falsy” it will result in no Alert. Otherwise it will result in an Alert. Sensor values are available in the sensor namespace (e.g. sensor.sensorABC), Calculated Fields are available in the calculation namespace (e.g. calculation.calcABC), Context Fields are available in the context namespace (e.g. context.contextABC), and other Alert Conditions are available in the alert namespace (e.g. alert.alertABC).

Examples

The formula, sensor.SensorA > 40 executes the relational operation, comparing SensorA to the literal 40. If this Condition Name was, DeviceThawed, then the resulting message to the Cloud could be:

{
 "sensor": {
  "SensorA": 39
 },
 "alert": {
  "DeviceThawed": false
 }
}

- OR -

{
 sensor: {
  "SensorA": 41
 },
 alert: {
  "DeviceThawed": true
 }
}

… with the later triggering an Alert with the defined Alert Type to Salesforce. Anytime an Alert is sent to Salesforce, the accompanying data message is included and can be used in your Process Builders or Flows. See the Processes section for more details.

The formula, calculation.CalcA === "Cold" executes the strictly-equal equality operator, comparing CalcA to the literal "Cold". If this Condition Name was, DeviceCold, then the resulting message to the Cloud could be:

{
 "sensor": {
  "SensorA": 39
 },
 "calculation": {
  CalcA: "Cold"
 },
 "alert": {
  "DeviceCold": true
 }
}

Sample Result: This field is automatically calculated based on the formula entered using the data provided in the sample message to populate the sensor and calculation namespaces.

Formula Editor

The Formula Editor now helps in writing formulas (both Calculated Fields and Alert Conditions). It allows the user to select any sensor, calculated field, digital twin value, function, or operator and will insert them at your cursor position.

Formula Editor

Examples

The formula, sensor.SensorA + sensor.SensorB, will add the aggregated value of SensorA to the aggregated value of SensorB. If this Calculated Field name was CalcA, then the resulting message to the Cloud could be:

{
 sensor: {
  "SensorA": 40,
  "SensorB": 2
 },
 calculation: {
  "CalcA": 42
 }
}

The formula, (sensor.SensorA > 40) ? "Not Cold" : "Cold", will execute the Javascript ternary operator (basically an assignable if-else statement). If this Calculated Field name was ColdState, then the resulting message to the Cloud could be:

{
 sensor: {
  "SensorA": 39
 },
 calculation: {
  "ColdState": "Cold"
 }
}

- OR -

{
 "sensor": {
  "SensorA": 41
 },
 "calculation": {
  "ColdState": "Not Cold"
 }
}.

Sample Result: This field is automatically calculated based on the formula entered using the data provided in the sample message to populate the sensor and calculation namespace.

State Machine Editor

A State Machine is a special kind of Calculated Field which tracks the active “State”, as well as any other custom local variables. When one of the conditional transitions changes the state, actions will be executed allowing you to implement any custom business logic necessary. For a full overview of the undelying State Machine engine see: State Machines.

The editor simplifies the creation / updating of these State Machines. Use the buttons at the top of the window for adding new Local Variable, States and Transitions.

State Machine Editor

Local Variables

Variable: The unique name of this variable
Value: Typically a sensor value. If instead you’d like to create a track a non-sensor value, use the “Formula…” option
Initialize Only: This variable will only be updated on initialization, not on every step. This allows you to modify and save the value in entry / during / exit actions

States

State: The unique name of the state. These state names can use a dot-notation to create sub-states as well (e.g. “running.normal” & “running.hot” would be sub-states of “running”)
Initial: Exactly 1 State must be marked as the initial state for each “level” (for sub-states). This is the state the machine will begin in for that “level”
Entry / During / Exit Actions: Click Add / Edit to modify the formulas. These actions are executed corresponding to state changes / steps.

Transitions

Priority: Numeric sort order for transitions, should be unique to the “From State”
From State: When the machine is in this active state, the condition will be evaluated. The first transition condition, ordered by Priority, which evalues to true will be executed.
To State: The state which will become active after the transition
Condition: Must evaluate to true/false. If true, this transition will execute.

Docs: Thing Type Editing

Mon, 01 Jan 0001 00:00:00 +0000

Thing-Types define the configuration for Edge Processing.

Top Level Configuration

Label: The label to use for the Thing-Type specification.
Is Active: If a Thing’s Thing-Type is not active (i.e. this option is deselected), the Thing’s data will not be aggregated and every message will be forwarded from the Gateway to the Cloud. It is not recommended to deactivate a Thing-Type that is assigned to Things, except for brief troubleshooting; otherwise, it could potentially result in higher costs and missed Alerts.
Sample Message: Used to auto-populate the Sensors section of the Thing-Type Specification.
Aggregate Type: Determines when to send the aggregated messages. It can be configured to “None”, “Seconds”, or “Count”.

None: Forward every message received from the device to the cloud.
Seconds: Aggregate the last N seconds of Thing data, where N is defined by the Aggregate Interval field.
Count: Aggregate the last N messages from a Thing, where N is defined by the Aggregate Interval field.

Aggregate Interval: Used in conjunction with the Aggregate Type field to determine the frequency of aggregation performed on the Gateway.
Offline Timeout (Seconds): Used to determine if a Thing is offline. If a device has not communicated in the time specified in this field, then an Offline Alert is sent to ServiceNow.

Sensor Settings

Include Undefined Sensors: When not selected any unrecognized sensor value(s) will be trimmed from the messages before processing
Enable Sensor Type Conversion: When selected the raw sensor values will be convereted into the Data Types specified below

Thing Type Record Page

Digital Twin Children

See the Digital Twins page for details on configuring this section.

Sensors

Label: The display name of the sensor data on plots.
Sensor Name: The name of the field in the actual Thing’s data message.

Example

Sensor Name = sensorABC, expects a field like {... "sensorABC": 123, ...} to be in the data message from the Thing.

Data Type: Specifies the type of data expected from each Sensor.
Aggregate Function: Determines how the data is aggregated in the Gateway.

NONE: Use the last received value as the value for the Sensor for Calculations, Alerts, and Cloud updates.
SUM: Sum all values received during the Aggregate Interval as the value for the Sensor for Calculations, Alerts, and Cloud updates.
AVG: Average all values received during the Aggregate Interval as the value for the Sensor for Calculations, Alerts, and Cloud updates.
MIN: Use the minimum of all values received during the Aggregate Interval as the value for the Sensor for Calculations, Alerts, and Cloud updates.
MAX: Use the maximum of all values received during the Aggregate Interval as the value for the Sensor for Calculations, Alerts, and Cloud updates.

Context Fields

Context Fields are configured in the Context Data Setup Page.

ML Models

See Machine Learning for more information.

Label: The label to use for the Calculated Field.
Model Name: The unique name of the model.
Input Features: The features required by this model. These will be mapped in the ML Inferences.
Model Parameters: Configuration values for the model itself.

ML Models

ML Inferences

This section defines all the ML Inference Fields for a Thing-Type. Each of these represent a result of executing an ML Model with a set of input values from IoT Sensors.

Label: The label to use for the ML Inference field.
Name: The name of the ML Inference field. It’s also the name referenced by other Calculations and Alerts.
Model: The ML Model (defined on the corresponding Gateway Thing Type) that will be executed.
Data Type: Determines the assumed data type for the result of the Calculation.
Formula: The mapping of Model Input Features to IoT Sensor values.

ML Inferences

Calculated Fields

Label: The label to use for the Calculated Field.
Field Name: The name of the field when this calculation is sent to the Cloud. It’s also the name referenced by other Calculations and Alerts.

Example

Field Name = calcABC results in {... "calcABC": 123, ...}, when data is sent to the Cloud and referenced as calculation.calcABC in other Calculations and Alerts.

Data Type: Determines the assumed data type for the result of the Calculation.
Formula: The actual formula to evaluate. The formula should be any Javascript statement that returns an assignable value. The formula can use any Sensor, Calculated Field, or Context Field in the computation. Sensor values are available in the sensor namespace (e.g. sensor.sensorABC), other Calculated Fields are available in the calculation namespace (e.g. calculation.calcABC), and Context Fields are available in the context namespace (e.g. context.contextABC).

Alert Conditions

Label: The label to use for the Alert Condition.
Condition Name: The name of the field when this alert is sent to the Cloud.

Example

Condition Name = alertABC results in {... "alertABC": 123, ...}, when data is sent to the Cloud.

Alert Type: Determines the type of Alert sent to ServiceNow. Each Alert sent to ServiceNow will include this Alert Type, which can be used in your Processes to take actions (like update the IoT Thing Status for a given Thing).
Alert Interval / Units: Determines how often this Alert is re-broadcasted. If the Alert condition has persisted longer than the amount of time specified by this field, the Alert will be sent to ServiceNow again to retrigger any automated processes. It is recommended to keep the Alert Interval at rather large values to avoid retriggering your processes.

Formula: The actual formula to evaluate. The formula should be a Javascript statement, and can use any Sensor or Calculated Field in the calculation. The formula should result in a boolean value; It will be evaluated as if it’s boolean — i.e. if the value is “falsy” it will result in no Alert. Otherwise it will result in an Alert. Sensor values are available in the sensor namespace (e.g. sensor.sensorABC), Calculated Fields are available in the calculation namespace (e.g. calculation.calcABC), Context Fields are available in the context namespace (e.g. context.contextABC), and other Alert Conditions are available in the alert namespace (e.g. alert.alertABC).

Examples

The formula, sensor.SensorA > 40 executes the relational operation, comparing SensorA to the literal 40. If this Condition Name was, DeviceThawed, then the resulting message to the Cloud could be:

{
 "sensor": {
  "SensorA": 39
 },
 "alert": {
  "DeviceThawed": false
 }
}

- OR -

{
 sensor: {
  "SensorA": 41
 },
 alert: {
  "DeviceThawed": true
 }
}

… with the later triggering an Alert with the defined Alert Type to ServiceNow. Anytime an Alert is sent to ServiceNow, the accompanying data message is included and can be used in your Flows. See the Processes section for more details.

The formula, calculation.CalcA === "Cold" executes the strictly-equal equality operator, comparing CalcA to the literal "Cold". If this Condition Name was, DeviceCold, then the resulting message to the Cloud could be:

{
 "sensor": {
  "SensorA": 39
 },
 "calculation": {
  CalcA: "Cold"
 },
 "alert": {
  "DeviceCold": true
 }
}

Sample Result: This field is automatically calculated based on the formula entered using the data provided in the sample message to populate the sensor and calculation namespaces.

Formula Editor

The Formula Editor Page now helps in writing formulas (both Calculated Fields and Alert Conditions). It allows the user to select data pills for any sensor, calculated field, digital twin value, function, or operator and copy them to the clipboard. The user can then paste the value anywhere in their formula field.

Formula Editor with Data Pills

Examples

The formula, sensor.SensorA + sensor.SensorB, will add the aggregated value of SensorA to the aggregated value of SensorB. If this Calculated Field name was CalcA, then the resulting message to the Cloud could be:

{
 sensor: {
  "SensorA": 40,
  "SensorB": 2
 },
 calculation: {
  "CalcA": 42
 }
}

The formula, (sensor.SensorA > 40) ? "Not Cold" : "Cold", will execute the Javascript ternary operator (basically an assignable if-else statement). If this Calculated Field name was ColdState, then the resulting message to the Cloud could be:

{
 sensor: {
  "SensorA": 39
 },
 calculation: {
  "ColdState": "Cold"
 }
}

- OR -

{
 "sensor": {
  "SensorA": 41
 },
 "calculation": {
  "ColdState": "Not Cold"
 }
}.

Sample Result: This field is automatically calculated based on the formula entered using the data provided in the sample message to populate the sensor and calculation namespace.

Docs: Thing Type Export

Mon, 01 Jan 0001 00:00:00 +0000

Thing Types definitions can be exported as a PDF document. This document captures the Sensors, Digital Twin Roles, Calculated Fields and Alert Conditions for all Thing Types. It’s a great way to capture and record the settings for sign-off / validation with the team.

Thing Types Export

Docs: Thing Type Synchronizing

Mon, 01 Jan 0001 00:00:00 +0000

Thing Types definitions are stored in both Salesforce and the IoT Cloud. You can update and Save them to Salesforce, and choose when to “Push” them to the cloud. The “Last Modified” and “Last Synchronized” Dates help you to track their status.

Note

In addition to synchronizing to/from the IoT Cloud, the Thing Types and all other Bolt Data Connect Metadata can be deployed between Sandboxes or Salesforce Orgs as Custom Metadata, using Change Sets, Packages, or any other Standard Salesforce Deployment tools.

Thing Types Change Mgmt

Note

As part of the Winter ‘25 Release, the “Last Modified” and “Last Synchronized” fields behave differently:

System Modstamp is the last modified date from the Custom Metadata record
Last Synchronized is no longer deployable between orgs. This removes confusion around whether or not Thing Types are synchronized after deploying them between Salesforce orgs.
The new “Multi-Sync” action is available as described below.

Import New Thing Types…

From the main Thing Types screen, you can Import Thing Types from the IoT Cloud into Salesforce.

Note

This import only brings the high level definition, but the full details can be imported using the “Sync ∇” functionality below.

Thing Types Import

Multi-Sync Δ (Push multiple Thing Types to the IoT Cloud)

From the main Thing Types screen, you can deploy multiple Thing Type definitions to the IoT Cloud (and the Edge Gateways).

Thing Types Multi Sync

Sync ∇ (Pull from the IoT Cloud)

When Editing a Thing Type, you can choose to Sync the full definition from the IoT Cloud into Salesforce. This would typically be used if the Thing Type has been edited and you wish to rollback, or if you are setting up a new Salesforce org but reusing a IoT Cloud org.

Thing Types Sync ∇

Sync Δ (Push to the IoT Cloud)

To deploy the latest Thing Type definition to the IoT Cloud (and the Edge Gateways), simply Sync the Thing Type.

Note

This Sync button is only enabled when the Thing Type has been successfully “Saved” since it was last Synchronized.

Audit Trail (From the IoT Cloud)

To view the history of a Thing Type definition in the IoT Cloud, use the View History button to view the Audit Trail.

Thing Type Audit Trail

Note

The View Detail button shows the detailed content behind each change
The Revert button will replace the Thing Type editor with the previous values. After reviewing the changes the user can then Save and Sync as they wish. As with all Custom Metadata, we CANNOT delete records.. that still needs to be done manually through the Salesforce Setup screen.

Docs: Thing Type Synchronizing

Mon, 01 Jan 0001 00:00:00 +0000

Thing Types definitions are stored in both ServiceNow and the IoT Cloud. You can update and Save them to ServiceNow, and choose when to “Push” them to the cloud. The “Last Modified” and “Last Synchronized” Dates help you to track their status.

Import New Thing Types…

From the main Thing Types screen, you can select the Import action to Import Thing Types from either the IoT Cloud or a local file into ServiceNow. There are two tabs, Remote Configurations and Upload File.

Remote Configurations

Note

This import brings the full details of the selected thing types and their dependencies stored on the IoT Cloud.

Thing Types Import

Thing Types Workspace Import

Upload File

Select a file saved using the Export action to import all of the thing types and their dependencies.

Note

This import brings the full details of the selected thing types and their dependencies stored on the local file.

Upload Thing Types

Export Thing Types

From the main Thing Types list page in the workspace, you can select thing types and click the Export action to save your thing types configurations to a local file. This file can be used to backup and move changes between instances.

Export Thing Types

Sync

Sync ∇ (Pull from the IoT Cloud)

When Editing a Thing Type, you can choose to Sync the full definition from the IoT Cloud into ServiceNow. This would typically be used if the Thing Type has been edited and you wish to rollback, or if you are setting up a new ServiceNow Instance but reusing a IoT Cloud org.

Sync Δ (Push to the IoT Cloud)

To deploy the latest Thing Type definition to the IoT Cloud (and the Edge Gateways), simply Sync the Thing Type.

Audit Trail (From the IoT Cloud)

To view the history of a Thing Type definition in the IoT Cloud, use the View History UI Action to view the Audit Trail.

Thing Type Audit Trail

Note

The View Detail button shows the detailed content behind each change
The Revert button will replace the Thing Type editor with the previous values. After reviewing the changes the user can then Save and Sync as they wish. This will not delete any records, including sensors, digital twin roles, alert conditions, calculated fields, context fields, ml models, and model interfaces. These records need to be deleted manually through any supported method in ServiceNow.

Docs: Visual Twins

Mon, 01 Jan 0001 00:00:00 +0000

Visual Twins represent an Image and Annotations for each Thing Type that together form a visual representation of a device with the Sensors, Calculated Fields and Alert Conditions overlayed on the image where they visually correlate.

Visual Twin Setup

Select a Thing Type to setup/edit it’s Visual Twin. If this is a first time setup you will see a message asking you to drag-and-drop an image file onto the editor.
Use the palette of drawing tools (Rectangles, Circles or Polygons) to draw the annotation areas. We recommend you use the selector tool to right-click and name these annotation areas so that the next steps are easier.
Select all of the Fields for a specific area in the “Available Fields” section.
Use the selector tool to right-click on the desired area and choose “Bind Values”. You will see these fields are now listed in the “Field Bindings” section for the desired area.

Visual Twin Editor

Note

To remove fields from an annotation area, simply unselect the fields and click the update button at the bottom of the “Field Bindings” section. You will see the fields are now returned to the “Available Fields” section.

Docs: Digital Twins

Mon, 01 Jan 0001 00:00:00 +0000

Digital Twins represent a group of Things that together form a composite device. They are closely related, each playing a role in a reusable Digital Twin Type, and can use values from the other Things in their own Calculated Fields and Alert Conditions.

Digital Twin Field Bindings

The 1st step in setting up Digital Twins is to configure which Thing Fields to use to represent the hierarchical and role relationship values.

Digital Twin Settings

Digital Twin Root: The fields from the Thing Object to the Root Thing and it’s unique Thing Identifier.
Digital Twin Parent: The fields from the Thing Object to the immediate Parent Thing and it’s unique Thing Identifier.
Digital Twin Role Name: The field to hold the role name that this Thing plays in the Digital Twin Type.

Digital Twin Children (in Thing Types)

The next step is defining the child roles in the Thing Type defintions that make up the Digital Twin Types. Go to the Thing Types setup page, and click into the desired parent Thing Type.

Digital Twin Children

Role Name: The role that the child Thing Type plays in the related group of Things.
Child Thing Type: The Thing Type of the Child.

Note

These role names are especially important when multiple instances of the same Thing Type are used as children in a parent Thing Type.

Digital Twin Types

After the Digital Twin Children are configured in one or more Thing Types, the Digital Twin Setup screen will now display all of the Digital Twin Types across all of the Thing Types.

Digital Twin Types

Note

Multi-level Digital Twin Types can be created by adding Digital Twin Children in the child Thing Types.

Digital Twin Diagram / Editor

On the Thing Record Page, add the IoT Digital Twin and easily view/edit the Digital Twin from any Thing in the configured Hierarchy.

The Diagram shows all of the most recent sensors and calculated fields from all Things in the same Digital Twin.

Digital Twin Editor

The Editor allows the user to assign Things into the roles in the Digital Twin, as well as easily navigate to any other thing in the Digital Twin.

Digital Twin Editor

Digital Twin API

We expose a REST Web Service to retrieve the Digital Twin data for any “Thing”. Use the following URL to retrieve the Digital Twin data:

YOUR_SALESFORCE_DOMAIN/services/apexrest/SPKI/DigitalTwin/SALESFORCE_ID

The REST service will return JSON in the following structure:

{
  "thingType" : "XXX",
  "sensors" : [
    { "key": "SENSOR_NAME_X", "value": "XXX" },
    { "key": "SENSOR_NAME_Y", "value": "YYY" }
  ],
  "role" : “XXX”,
  "id" : "SALESFORCE_ID",
  "externalId" : "UNIQUE_KEY",
  "children" : [ … Recursive structure for nested Digital Twins … ]
}

Docs: Digital Twins

Mon, 01 Jan 0001 00:00:00 +0000

Digital Twins represent a group of IoT Connected Assets that together form a composite device. They are closely related, each playing a role in a reusable Digital Twin Type, and can use values from the other IoT Connected Assets in their own Calculated Fields and Alert Conditions.

Digital Twin

The first step is creating an IoT Digital Twin Role record in the Thing Type record that make up the IoT Digital Twin Role. Go to the Thing Types setup page, and click into the desired parent Thing Type.

Digital Twin Children

Name: The role that the child Thing Type plays in the related group of IoT Connected Assets.
Label: The label of the IoT Digital Twin Role.
IoT Thing Type: The Thing Type of the Parent.
Child Thing Type: The Thing Type of the Child.

Digital Twin Diagram

On the IoT Connected Asset Record Page, you will see the IoT Digital Twin section where you can easily view the Digital Twin from any Connected Asset in the configured Hierarchy.

The Diagram shows all of the most recent sensors and calculated fields from all Connected Assets in the same Digital Twin.

Digital Twin Diagram

Docs: Context Data

Mon, 01 Jan 0001 00:00:00 +0000

Easily Sync Salesforce Data (related to the Thing Object) to the IoT Cloud and Edge Gateway. This Context data can be used in Calculations and Alert Conditions (by using the context group - e.g. context.someField == 'Gold'), to enhance and provide flexibility in your Thing-Type Specifications.

All Context fields are synced on a schedule, or can be manually synced for special cases and troubleshooting.

Context Data Settings

Global Context Fields

Global Context Fields are synced for all Things, regardless of their Thing-Type.

Select New.
In the new row, select Global Settings from the dropdown.
Define the reader friendly Label for the field.
Define the Field Name to use in calculations and alerts.
Name Restrictions
- Must start with a letter.
- Can only contain letters, numbers, and _.
- Must not contain any spaces.
Select the Object field to associate with this Context field.

Thing-Type Context Fields

Thing-Type Context Fields are only synced for Things which match the Thing-Type specified.

Steps for Thing-Type Context Fields are the same as for Global Context fields, except Step 2: select the desired Thing-Type from the drop down in place of Global Settings.

Context Synchronization

The sync schedule for the Context fields is managed in the lower section of the Context Data settings page.

If an existing schedule has already been configured, select Disable prior to configuring the new schedule.
In the Schedule drop-down menu, select the desired frequency.
Enter the appropriate value in the At field.
- Hourly: Define how many minutes past the hour to run the sync.
- Daily: Define the time of day.
- Weekly: Define the day of the week and time of day.
- Monthly: Define which day of the month and the time of day.
Select Enable.

FYI

The chron expression is shown in the Status field.

Remove Context Field

Select the link under the Custom Metadata Record column.
Select the Delete button toward the top of the metadata record.

Docs: Context Data

Mon, 01 Jan 0001 00:00:00 +0000

Easily Sync ServiceNow Data (related to the IoT Connected Assets) to the IoT Cloud and Edge Gateway. This Context data can be used in Calculations and Alert Conditions (by using the context group - e.g. context.someField == 'Gold'), to enhance and provide flexibility in your Thing-Type Specifications.

All IoT Context fields are synced with a scheduled job, or can be manually synced for special cases and troubleshooting.

Context Data Record Page

Global Context Fields

IoT Context Fields without a specified Thing Type are known as Global Context Fields. Global Context Fields are synced for all Connected Assets, regardless of their Thing-Type.

Select New.
In the new record screen, leave the Thing Type field empty.
Define the reader friendly Label for the field.
Define the Field Name to use in calculations and alerts.
Name Restrictions
- Must start with a letter.
- Can only contain letters, numbers, and _.
- Must not contain any spaces.
Select the Asset Table corresponding to the asset type for your connected asset.
Select the Asset Field to associate a field on the Asset Table with this IoT Context Field.

Thing-Type IoT Context Fields

Thing-Type IoT Context Fields are only synced for Connected Assets which match the Thing-Type specified.

Steps for Thing-Type IoT Context Fields are the same as for Global Context fields, except Step 2: select the desired Thing-Type in the Thing Type field.

Context Synchronization

The sync schedule for IoT Context Fields is managed in the IoT_Context_Job scheduled job. This can be found in All -> System Definition -> Scheduled Jobs.

In the Run field, select the desired frequency.
- Periodically: Define the time between runs.
- Daily: Define the time of day.
- Weekly: Define the day of the week and time of day.
- Monthly: Define which day of the month and the time of day.
In the field that shows up depending on your choice, fill out the appropriate values according to your desired frequency.
Select Active.
Save the record.

Remove IoT Context Field

Open the desired IoT Context Field record to be deleted.
Select the Delete button toward the top of the record.

Docs: Sensor Data

Mon, 01 Jan 0001 00:00:00 +0000

Sensor data typically lives solely in the IoT Cloud. We realize there are some workflows which required importing data into Saleforce Objects. For such workflows, we enable a Sensor Data Sync which pulls the latest sensor data from the IoT Cloud into the Object you specify in IoT Setup.

Sensor Data Settings

Field Definitions

Sensor Object: This field defines the Object to pull data into.; The Object must have at least 4 fields to tie to: External ID, Sensor Name, Sensor Value, and Thing Lookup.
Sensor External ID: The field to hold the External ID of the sensor data object.
Sensor Name: The field to hold the name of the sensor data.
Sensor Value: The field to hold the value of the sensor data.
Sensor Timestamp: The field to hold the timestamp of the sensor data.
Thing Lookup: The field to hold the Lookup to the related Thing Object.

Asset Attributes

Asset Attributes is a new Standard Object used in Salesforce Field Service and Manufacturing Cloud in Usage-Based and Condition-Based PM Plans. We’ve added support for populating these objects automatically by synchronizing the values from the IoT Cloud as well as automating the creation of the Asset Attribute Definitions.

Asset attributes provide a better understanding of the condition of assets and let mobile workers repair and maintain those assets in the field more efficiently. An asset usually has multiple attributes. You can create attributes by defining the values and data types of attribute definitions and associating them with the asset attributes.

Ability to easily sync and populate Asset Attributes with clicks-not-code
Full automation of Asset Attribute Definitions, reducing manual setup tasks
Ability to filter which Sensors / Calculated Fields / Alert Conditions are sync’d to better support the Asset Attributes data limits
Asset attribute support in Servitization Plans

Sensor Data Asset Attributes

Note

25 Attributes per Asset limit
Asset Attribute is a “External Object”, and not allowed to have Custom Fields
Due to being an External Object, No “Timestamp” Field is available, only the “Last Modified”. This impacts the Servitization ability to bill accurately.
We Auto-Create Attribute Definitions by Field Name & Data Type (Sensor/CalcField/AlertCondition) - so these names to be be unique or consistent across all of the configured Thing Types
See Asset Attributes Limitations for full details

Advanced Sensor Bindings

A sensor value can be used as the “Timestamp” of the synchronized Sensor Data. This Timestamp influences downstream processes like Servitization and Reporting. If these fields are NOT filled in, the system will use the default Timestamp in our IoT metadata which indicates the date/time when we received the IoT message.

Timestamp Sensor: The name of the Sensor (or Calculated Field) to use as the Timestamp of all Sensor Data values
Timestamp Format: The format of the above Timestamp Sensor. Choices are: GMT, Local, Epoch. If using GMT or Local the value should be an ISO formatted date-time, whereas Epoch should be in milliseconds.
Sync Thing Status: Indicator of whether or not to Sync the Thing Status (Normal/Alert/Offline) from the IoT Cloud to Salesforce.
Sync All Fields: Indicator of whether or not to Sync All Fields from the IoT Cloud to Salesforce. If unselected, an editor will be displayed to select which IoT Fields to synchronize, including helper buttons to select all, servitized values only, or sensors only.

Sensor Data Asset Attributes

Sensor Synchronization

The sync schedule for the Sensor Data is managed in the lower section of the Sensor Data settings page.

If an existing schedule has already been configured, select Disable prior to configuring a new schedule.
In the Schedule drop-down menu, select the desired frequency.
Enter the appropriate value in the At field
- Hourly: Define how many minutes past the hour to run the sync.
- Daily: Define the time of day.
- Weekly: Define the day of the week and time of day.
- Monthly: Define which day of the month and the time of day.
Select Enable.

FYI

The chron expression is shown in the Status field.

Docs: Sensor Data

Mon, 01 Jan 0001 00:00:00 +0000

Sensor data typically lives solely in the IoT Cloud. We realize there are some workflows which required importing data into ServiceNow Tables. For such workflows, we enable a Sensor Data Sync which pulls the latest sensor data from the IoT Cloud into the Asset Attributes Table.

Sensor Synchronization

The sync schedule for the Sensor Data is managed in the IoT_Attributes_Job scheduled job. This can be found in All -> System Definition -> Scheduled Jobs.

In the Run field, select the desired frequency.
- Periodically: Define the time between runs.
- Daily: Define the time of day.
- Weekly: Define the day of the week and time of day.
- Monthly: Define which day of the month and the time of day.
In the field that shows up depending on your choice, fill out the appropriate values according to your desired frequency.
Select Active.
Save the record.

Docs: Auto Registration

Mon, 01 Jan 0001 00:00:00 +0000

The Auto-Registration settings focus on how the IoT Registration records are processed.

Auto-Registration Setup

Registration Settings

Registration to Thing Lookup: The field on the IoT Registration object to hold the Lookup to the related Thing Object.

Registration Expressions

Thing Expression: The expression used to find/lookup the corresponding Thing/Asset record

Thing Expression

This expression will be used by the Auto-Registration job to lookup the Thing record. Match fields from the Thing/Asset to the IoT Registration record. If necessary, custom formula fields or other automated fields can be added to either object and configured here.

Registration Job

The schedule for the Registration Job is managed in the lower section of the page.

If an existing schedule has already been configured, select Disable prior to configuring a new schedule.
In the Schedule drop-down menu, select the desired frequency.
Enter the appropriate value in the At field
- Hourly: Define how many minutes past the hour to run the sync.
- Daily: Define the time of day.
- Weekly: Define the day of the week and time of day.
- Monthly: Define which day of the month and the time of day.
Select Enable.

FYI

The chron expression is shown in the Status field.

IoT Registration Object

IoT Registration records will be auto-created by the IoT Cloud as unrecognized IoT Things are detected, or they can also be created in Salesforce by an integration or any other automation. As the Auto-Registration Job runs it will try to assign any missing data and then call the IoT Cloud API to Register the Thing/Asset.

Admins can create reports on this object to monitor the status / values:

Status will change from New to Registered if successfully registered
The Is Missing Data field will be checked if the Thing, Gateway or Thing Type cannot be determined
The Results field will contain details from the API calls

IoT Registration Objects

NOTE

If the status is set to “Removed” the Auto-Registration Job will call the IoT Cloud API to Deregister the Thing/Asset and then change the status to “Deregistered”.

Docs: Auto Registration

Mon, 01 Jan 0001 00:00:00 +0000

IoT Registration

IoT Registration records will be auto-created by the IoT Cloud as unrecognized Connected Assets are detected, or they can also be created in ServiceNow by an integration or any other automation. As the Auto-Registration Business Rule runs it will try to assign any missing data and then call the IoT Cloud API to Register the Connected Asset. By default, IoT Registration records contain text fields containing the IoT Thing ID and the Gateway ID. A flow must be created to fill in the fields for an Asset record, a Gateway Record, and a Thing Type record based on these two fields. This process will be different for every Client due to different naming conventions and preferences. Once these fields are updated on the record, the Auto-Registration Business Rule will check the record fr any missing data. If there is missing data, the Business Rule will set the Missing Data field to true and will provide details in the Results field. If the necessary fields are not missing, the Business Rule will create a Connected Asset record and register it with the IoT Cloud.

Registration Record with a Missing Asset Field

Successful Registration Record

NOTE

Any update to an IoT Registration record will cause the Auto-Registration Business Rule to check the updated record and attempt to create and register an Asset. For example, manually adding an Asset to an IoT Registration record that is only missing an Asset field will result in the Auto-Registration Business Rule to attempt to create and register a Connected Asset.

Example Auto-Registration Flow

The provided example is not the only way to implement this. As long as the Asset, Gateway, and Thing Type fields are filled in and the IoT Registration record is updated, the Auto-Registration Business Rule will attempt to create and register a Connected Asset.

Example Auto Registration Flow

For the following example implementation for Flow Step 1 above, the Client has a unified naming rule set for all Assets, Connected Assets, and Thing Types as follows:

Connected Asset’s IoT Thing ID’s always begin with the Thing Type name
Asset Tags always start with “P1” (ex: P10001, P10002, P19993, etc)
Connected Asset’s IoT Thing ID’s always have “_P1” followed by the Asset Tag they relate to after the Thing Type name (ex: Brewing_Keg_P10001, Brewing_Keg_P10002, Brewing_Keg_P19993, etc)

Example Auto Registration Flow

Docs: Geo-Coding

Mon, 01 Jan 0001 00:00:00 +0000

Bolt Data Connect can be configured to automatically lookup the Geo-Code (longitude/latitude) of Connected Assets (or other related objects).

Automatic Geo-Coding

Address Definitions

Address SObject: Select the Object which needs to be Geo-Coded
Compound Address Field OR Address Fields: Fill in EITHER the Compound Address Field OR the individual Address Fields
Formatted Address Field: Select a field to save the formatted address. This is required for optimizing calls and reducing costs.
GeoCode Field OR Longitude/Latitude Fields: Fill in EITHER the GeoCode Field OR the individual Longitude/Latitude Fields

IoT Address Definition

NOTE

We have pre-loaded a record for the standard Asset object, but it can be edited or cloned in the Salesforce Setup > Custom Metadata screen.

Address Formats

Address Format: The formatted combination/order of the address fields
Countries: The Country Codes which will utilize this format

IoT Address Formats

NOTE

We have pre-loaded records for all major Country formats, but it can be edited in the Salesforce Setup > Custom Metadata screen.

Geo-Coding Job

The Geo-Code Job will automatically process all the records of the configured objects which have not yet been Geo-Coded.

If an existing schedule has already been configured, select Disable prior to configuring a new schedule.
In the Schedule drop-down menu, select the desired frequency.
Enter the appropriate value in the At field
- Hourly: Define how many minutes past the hour to run the sync.
- Daily: Define the time of day.
- Weekly: Define the day of the week and time of day.
- Monthly: Define which day of the month and the time of day.
Select Enable.

FYI

The chron expression is shown in the Status field.

Docs: Data Snapshots

Mon, 01 Jan 0001 00:00:00 +0000

Data Snapshots provide a mechanism to capture sensor data for a specific slice of time. Each Data Snapshot is automatically associated to a Thing, but can also be associated with a secondary parent Object.

You can define a list of allowable secondary parent Objects on the Data Snapshot setup screen.

Data Snapshot Setup Screen

Once configured, Data Snapshots can be viewed on the Parent Object within the IoT Thing Chart Lightning Web Component.

Data Snapshot on an example Work Order

Add Parent Object

Note

Each Parent Object must have a lookup field for the configured Thing Object.

Select New.
Select the new Parent Object from the Parent Object field.
Select the field from the new Parent Object used to lookup the related Thing Object.

Remove Parent Object

Under the Parent Object you wish to remove, select the View Metadata link.
On the new screen, select the Delete button toward the top of the metadata record.

Docs: Alert History

Mon, 01 Jan 0001 00:00:00 +0000

Bolt Data Connect can be configured to send IoT Alerts from the IoT Cloud to Salesforce when certain conditions or signals are received from the connected Things. These IoT Alerts are Platform Events, and can be processed in real time using Process Builders, Flows or Triggers. If you would like to also save copies of these IoT Alerts in Salesforce, simply enable this setting and Bolt Data Connect will automatically save received IoT Alerts in the “IoT Alert History” Object.

Alert History Setup

Field Definitions

Save Alert History: This field enables / disables the creation of “IoT Alert History” records.
Thing Lookup: The field on the “IoT Alert History” Object which represents the Lookup to the related Thing Object. (Default should be “IoT Asset”)
History to Save (Days): The number of days of history to save (used by the Cleanup job below).

Alert History Cleanup

The Cleanup Job will delete these “IoT Alert History” records based on the provided “Days” above.

If an existing schedule has already been configured, select Disable prior to configuring a new schedule.
In the Schedule drop-down menu, select the desired frequency.
Enter the appropriate value in the At field
- Hourly: Define how many minutes past the hour to run the sync.
- Daily: Define the time of day.
- Weekly: Define the day of the week and time of day.
- Monthly: Define which day of the month and the time of day.
Select Enable.

FYI

The chron expression is shown in the Status field.

Docs: Alert History

Mon, 01 Jan 0001 00:00:00 +0000

Bolt Data Connect is configured to send IoT Alerts from the IoT Cloud to ServiceNow when certain conditions or signals are received from the IoT Connected Assets. These alerts create IoT Alert History records, and can be processed in real time using Flows with Record Created Triggers.

Here is a sample Flow which creates a Work Order that can customize and automate alerts in any way.

Record Create Trigger in Flow Designer

Create Workflow in Flow Designer

Docs: Servitization Setup

Mon, 01 Jan 0001 00:00:00 +0000

Note

For an explanation of what Servitization is, visit the Servitization help document.

The below settings control how the Servitization job will generate Servitization Details and also control which output Objects will be created from the details.

Servitization Settings

Field Definitions

Servitization Detail to Thing Lookup: Select the Servitization Detail field which represents a lookup to the Thing Object. (Typically “Asset”)
Servitization Coverage to Thing Lookup: Select the Servitization Coverage field which represents a lookup to the Thing Object. (Typically “Asset”)
Thing Business Hours: The field from your Thing object which is a Lookup to Business Hours. OPTIONAL: Only needed if each Thing needs to specify the Business Hours to use. Can also specify a default on each Servitization Plan.

Servitization Mappings

These Object Mappings specify which output Objects are created, and the field level mappings of each. For example, you might want to create an “Order/OrderLine” to represent your Servitization Output. Alternatively, you might instead want to user “Quote/QuoteLine” or “Proforma Invoice/Lines”.

Note

Click into the Output Mapping first, save and return to this screen before clicking into the Output Line Mapping.

Select the Target Object first

Note
Source Objects are predefined and are available in Field Mappings below
For any output field you’d like to populate, select a Mapping Type.
Select the Source Field or specify a Value

Hint
Formula fields are powerful for source fields
Click Save and return to Servitization Settings

Servitization Settings

Note

The Mapping Type of “IoT Field” is not applicable to Servitization. It is primarily for Alert Handling mappings.

Servitization Job Scheduling

The schedule for the Servitization generation is managed in the lower section of the Servitization settings page.

Recommendation

We recommend a daily schedule, even if your output is Weekly or Monthly. This allows for a more granular capturing of Servitization Details.

If an existing schedule has already been configured, select Disable prior to configuring a new schedule.
In the Schedule drop-down menu, select the desired frequency.
Enter the appropriate value in the At field
- Hourly: Define how many minutes past the hour to run the sync.
- Daily: Define the time of day.
- Weekly: Define the day of the week and time of day.
- Monthly: Define which day of the month and the time of day.
Select Enable.

FYI

The chron expression is shown in the Status field.

Docs: Thing Downtime

Mon, 01 Jan 0001 00:00:00 +0000

Thing Downtime records can be populated automatically by using the Offline and Normal Thing Status Alerts sent from the IoT Cloud.

Thing Downtime Settings

Field Definitions

Downtime Start: The field from the Thing Object to hold the Datetime of when a new Downtime has begun.; This field will only be populated when a Thing is currently Offline. When the Thing returns to Normal this field will be cleared and a related Downtime Object will be created.
Downtime Object: This field defines the Object to create to represent a Downtime Period of time.; The Object must have at least 4 fields to tie to: Downtime Type, Start Datetime, End Datetime, and Thing Lookup.
Downtime Type: The field to hold the type of Downtime (will always be populated with a value of Unplanned in this field for automatically created records based on Thing Status IoT Alerts).
Start Datetime: The field to hold the value of the Date/Time when the Downtime Period began.
End Datetime: The field to hold the value of the Date/Time when the Downtime Period ended.
Thing Lookup: The field to hold the Lookup to the related Thing Object.

Sample Downtime

Following is a sample Thing Downtime Object that was created based on the settings seen above.

Sample Thing Downtime

Docs: Data Lake Calculations Setup

Mon, 01 Jan 0001 00:00:00 +0000

The below settings control which metric frequency(s) and calulations will be collected for each Thing Type.

Data Lake Calculations Editor

Data Lake Calculation Editor

Metrics Frequency(s)

Select the 1 Month, 3 Month, 6 Month and/or 12 Month Frequency fields to enable the calculation of metrics for each of these time periods. These frequency values will be calculated for all of the selected Metrics Fields below.

Metrics Fields

Select the metric calculations for each of the Thing Type’s:

Sensors
Calculated Fields
Model Inferences
Alert Conditions

Note

All fields can calculate COUNT values, but only Numeric fields allow for the calculation of the following values:

Data Lake Calculations Synchronization

When the Job below is run, the calculated metrics from the IoT Cloud will be imported into the following fields on the IoT Sensor Data Object in Salesforce:

SPKI__DLC_1_Month_XXX
SPKI__DLC_3_Month_XXX
SPKI__DLC_6_Month_XXX
SPKI__DLC_12_Month_XXX

Data Lake Calculations Sync Fields

COUNT Metrics

The COUNT values of Boolean fields (including all Alert Conditions) will synchronize to the COUNT_True and COUNT_False fields.
All other field types will synchronize to the COUNT_JSON field, with all unique values and counts in JSON format.

Data Lake Calculations Job Scheduling

The schedule for the Data Lake Calculations sync job is managed in the lower section of the Data Lake Calculations settings page, ONLY when a Thing Type is NOT selected.

Recommendation

We recommend a monthly schedule, since these metrics are only calculated in the IoT Cloud monthly as well.

If an existing schedule has already been configured, select Disable prior to configuring a new schedule.
In the Schedule drop-down menu, select the desired frequency.
Enter the appropriate value in the At field
- Hourly: Define how many minutes past the hour to run the sync.
- Daily: Define the time of day.
- Weekly: Define the day of the week and time of day.
- Monthly: Define which day of the month and the time of day.
Select Enable.

FYI

The chron expression is shown in the Status field.

Data Lake Calculations Dashboard & Reports

We’ve including Reports to show all synchronized metrics for each Frequency.

Data Lake Calculations Dashboard

Docs: Machine Learning

Mon, 01 Jan 0001 00:00:00 +0000

Machine Learning in BDC IoT Cloud

The diagram illustrates the integration of Machine Learning (ML) Data Science with a BDC IoT Cloud ecosystem, involving various components responsible for data processing, model training, and IoT operations.

Machine Learning Model Process

The machine learning model process involves data engineering, where raw data is prepared and then stored in a repository. Data scientists build and train machine learning models using this data. The trained ML models generate inferences based on IoT data, enabling the BDC IoT Cloud to manage and automate IoT devices through the Rules-Engine. Salesforce provides external business integration to align IoT operations with business processes.

Data Pipeline (Data Engineering)

Preprocess Data: Raw data is collected and preprocessed for quality and format consistency by a Data Engineer.
Data Repository: Once preprocessed, the data is stored in a repository, which serves as input for the Model Pipeline.

Model Pipeline (Data Science)

Feature Engineering and Training: The Data Scientist processes data from the repository, applying feature engineering techniques and training machine learning models.
Evaluation: After training, the model undergoes evaluation to ensure its performance on test datasets.

Release Pipeline

The Release Pipeline handles the deployment of the trained and evaluated model. This process includes:
- Deploy: Deploying the model to production infrastructure.
- Approve: Stakeholder approval.
- Profile: Analyzing the model’s performance.
- Validate: Ensuring the model meets functional and performance requirements.
- Package: Packaging the final model for release.
The model is stored in the Model Registry, which serves as a centralized repository for managing and tracking machine learning models. The Model Registry ensures that every version of the model, along with its metadata (such as deployment versions, and associated configurations) is easily accessible for future use or updates.

BDC Data Cloud and Salesforce

The ML Model developed in the Machine Learning Data Science section produces Model Inferences based on IoT data. These inferences are fed into the BDC IoT Rules-Engine, where they help automate processes within the BDC IoT Cloud by applying decision-making logic.
The interation between Salesforce and BDC IoT Cloud helps to synchronize customer data, device management, and analytics with business processes.

Docs: Machine Learning

Mon, 01 Jan 0001 00:00:00 +0000

Machine Learning in BDC IoT Cloud

Machine Learning Model Process

The machine learning model process involves data engineering, where raw data is prepared and then stored in a repository. Data scientists build and train machine learning models using this data. The trained ML models generate inferences based on IoT data, enabling the BDC IoT Cloud to manage and automate IoT devices through the Rules-Engine. ServiceNow provides external business integration to align IoT operations with business processes.

Data Pipeline (Data Engineering)

Preprocess Data: Raw data is collected and preprocessed for quality and format consistency by a Data Engineer.
Data Repository: Once preprocessed, the data is stored in a repository, which serves as input for the Model Pipeline.

Model Pipeline (Data Science)

Feature Engineering and Training: The Data Scientist processes data from the repository, applying feature engineering techniques and training machine learning models.
Evaluation: After training, the model undergoes evaluation to ensure its performance on test datasets.

Release Pipeline

The Release Pipeline handles the deployment of the trained and evaluated model. This process includes:
- Deploy: Deploying the model to production infrastructure.
- Approve: Stakeholder approval.
- Profile: Analyzing the model’s performance.
- Validate: Ensuring the model meets functional and performance requirements.
- Package: Packaging the final model for release.
The model is stored in the Model Registry, which serves as a centralized repository for managing and tracking machine learning models. The Model Registry ensures that every version of the model, along with its metadata (such as deployment versions, and associated configurations) is easily accessible for future use or updates.

BDC Data Cloud and ServiceNow

The ML Model developed in the Machine Learning Data Science section produces Model Inferences based on IoT data. These inferences are fed into the BDC IoT Rules-Engine, where they help automate processes within the BDC IoT Cloud by applying decision-making logic.
The interation between ServiceNow and BDC IoT Cloud helps to synchronize customer data, device management, and analytics with business processes.

Docs: Writing Formulas

Mon, 01 Jan 0001 00:00:00 +0000

Edge processing takes sensor data, aggregates it, and computes all the Calculations and Alerts all according to your Thing Type Specifications.

The following section describes the syntax for writing these functions. The base syntax for all these formulas is JavaScript (specifically Node.js).

Function Basics

Let’s assume our Example IoT Connected Asset produces a message which looks like this:

interface thing_message {
  pressure_volts: number;
  temperature: number;
  state: string;
}

The Gateway starts building the following message:

const message = {
  sensor: {
    pressure_volts: 5,
    temperature_volts: 6,
    state: "on",
  },
};

Let’s write the function for a Calculation named pressure_psi:

(sensor.pressure_volts * 20) / 10;

Sensor Namespace

In the above formula we have access to the current IoT Connected Asset’s aggregated sensor data under the namespace sensor. There are 4 additional namespaces covered in Namespaces.

The Gateway message now looks like:

const message = {
  sensor: {
    pressure_volts: 5,
    temperature_volts: 6,
    state: "on",
  },
  calculation: {
    pressure_psi: 10,
  },
};

Now let’s write a formula for an alert on pressure named overpressure:

sensor.state === "on" && calculation.pressure_psi > 15;

JavaScript

Any valid JavaScript which returns a value can be used in these Calculations and Alerts. Take a look at JavaScript Basics for help on basic operators.

Our Gateway message now looks something like:

const message = {
  sensor: {
    pressure_volts: 5,
    temperature_volts: 6,
    state: "on",
  },
  calculation: {
    pressure_psi: 10,
  },
  alert: {
    overpressure: false,
  },
};

This is the basic structure you’re putting together when building your Thing Type specification.

Namespaces

There are 5 base namespaces which can be used to access data from these formulas:

sensor: Provides access to all the latest aggregated sensor values. Aggregation is defined by the Thing Type specification Salesforce, ServiceNow.
calculation: Provides access to all the latest calculated values. Calculations are defined by the Thing Type specification Salesforce, ServiceNow.
alert: Provides access to all the latest alert values. Alerts are defined by the Thing Type specification Salesforce, ServiceNow.
context: Provides access to all the latest context values. Context is defined by the Context settings Salesforce, ServiceNow.

Context settings.

twin: Provides access to all the the following values:

role

the Digital Twin role for the referenced IoT Connected Asset

Priority

When specifying calculations and alerts in the thing-type specification (Salesforce, ServiceNow), the priority defines the execution order of each calculation/alert. Alerts are always evaluated after all calculations. Within each group (calculations and alerts), formulas are evaluated in priority order from smallest (0) to largest (infitinity). A calculatoin with priority 0 will be evaluated before a calculation with priority 1 and so on. For elements with equal priority, their order relative to each other is arbitrary. So in the following example:

calcA: priority = 0
calcB: priority = 10
calcC: priority = 10
calcD: priority = 11

… calcA is evaluated first followed by calcC and calcB (in no defined order), then finally calcD is evaluated. Once all the calculations are evaluated, the alerts are then evaluated.

When referring to calculations which are evaluated later in the cycle from within calculations which happen earlier, there will be a unit-delay in the value retrieved.

Example:

calcA: priority = 0, formula = (calculation.calcB === undefined) ? 0 : calculation.calcB + 1

calcB: priority = 1, formula = calculation.calcA + 1

On the first pass, calculation.calcB will be undefined, so calcA will be 0, calcB is then 1

On the second pass, calcA will be 2, calcB will be 3

… and so on

Specification Metadata Access

In general, when you reference a sensor, calculation, or alert within a formula, it implicitly retrieves it’s current value (i.e. calculation.calcAbc implicitly becomes calculation.calcAbc.value). Alternatively, there are other metadata which can be retrieved from the given element.

In addition to the implicit value, the following parameters are available:

Sensor
- name: the calculation name (e.g. sensor.sensorAbc.name = "sensorAbc")
- label: the calculation label (e.g. sensor.sensorAbc.label = "Sensor ABC")
- dataType: the calculation data-type (e.g. sensor.sensorAbc.dataType = "Number")
- aggregateType: the sensor’s aggregation-type (e.g. sensor.sensorAbc.aggregateType = "Seconds")
- aggregateFunction: the sensor’s aggregation-function (e.g. sensor.sensorAbc.aggregateFunction = "MAX")
- aggregateInterval: the sensor’s aggregation-interval (e.g. sensor.sensorAbc.aggregateType = 300)
- isStored: true if the sensor is stored in the cloud (e.g. sensor.sensorAbc.isStored = true)
- storageDataType: the cloud storage type (e.g. sensor.sensorAbc.isStored = "Double")
Calculation
- name: the calculation name (e.g. calculation.calcAbc.name = "calcAbc")
- label: the calculation label (e.g. calculation.calcAbc.label = "Calculation ABC")
- formula: the calculation formula (e.g. calculation.calcAbc.formula = "1 + 1")
- priority: the calculation priority (e.g. calculation.calcAbc.priority = 14)
- isActive: true if the calculation is active (e.g. calculation.calcAbc.isActive = true)
- isStored: true if the calculation is stored in the cloud (e.g. calculation.calcAbc.isStored = true)
- storageDataType: the cloud storage type (e.g. calculation.calcAbc.isStored = "Double")
Alert
- name: the alert name (e.g. alert.alertAbc.name = "alertAbc")
- label: the alert label (e.g. alert.alertAbc.label = "Alert ABC")
- alertType: the alert-type (e.g. alert.alertAbc.alertType = "Threshold")
- alertInterval: the interval which the alert re-drives to ServiceNow (e.g. alert.alertAbc.alertInterval = 3600)
- formula: the alert formula (e.g. alert.alertAbc.formula = "calculation.calcAbc > 1")
- priority: the alert priority (e.g. alert.alertAbc.priority = 14)
- isActive: true if the alert is active (e.g. alert.alertAbc.isActive = true)
- isStored: true if the alert is stored in the cloud (e.g. alert.alertAbc.isStored = true)

Examples

Example 1 Constant

Name: example1

Description: Always return a constant value for the calculation or alert.

Formula:

"hello world";

Result: constant { ... example1: 'hello world' ... } in each message

Example 2 Basic Arithmetic

Name: example2

Description: Scale sensorA

Formula:

sensor.sensorA * 10 + 2;

Result:

{
  "sensorA": 3,
  "example2": 32
}

Example 3 Conditional

Name: example3

Description: If the IoT Connected Asset’s sensorA is over 10, calculate, otherwise return 0.

Formula:

sensor.sensorA > 10 ? sensor.sensorB * 50 : 0;

Results:

{
  sensorA: 3,
  sensorB: 6,
  example3: 0
}

{
  sensorA: 11,
  sensorB: 6,
  example3: 300
}

Alternate

if (sensor.sensorA > 10) {
  return sensor.sensorB * 50;
} else {
  return 0;
}

Example 4 Digital Twin

Name: example4

Description: If the IoT Connected Asset’s parent is powered on, calculate, otherwise return 0.

Formula:

$parent.calculation.powerOn ? sensor.sensorB / $parent.sensor.inputVoltage : 0;

Results:

parentId: {
  sensor: {
    inputVoltage: 12
  },
  calculation: {
    powerOn: true
  }
}

{
  "sensorB": 6,
  "example4": 0.5
}

parentId.sensor.inputVoltage: 0
parentId.calculation.powerOn: false

{
  "sensorB": 6,
  "example4": 0
}

Alternate

if ($parent.calculation.powerOn) {
  return sensor.sensorB / $parent.sensor.inputVoltage;
} else {
  return 0;
}

Example 5 Context

Name: example5

Description: If the IoT Connected Asset’s entitlement level is either Platinum or Gold, evaluate the threshold, otherwise return false.

Formula:

["platinum", "gold"].includes(context.entitlementLevel.toLowerCase())
  ? calculation.someValue > 100
  : false;

Results:

context.entitlementLevel = "Gold";

{
  "someValue": 101,
  "example5": true
}

context.entitlementLevel = "Silver";

{
  "someValue": 101,
  "example5": false
}

Alternates

if (["platinum", "gold"].includes(context.entitlementLevel.toLowerCase())) {
  return calculation.someValue > 100;
} else {
  return false;
}

function isCovered(level) {
  const coveredLevels = ["platinum", "gold"];
  return coveredLevels.includes(level.toLowerCase());
}

if (isCovered(context.entitlementLevel)) {
  return calculation.someValue > 100;
} else {
  return false;
}

Docs: Expressions & Operators

Mon, 01 Jan 0001 00:00:00 +0000

Arithmetic

+: Addition

const newNumber = 1 + 1; // 2
const newString = "1" + "1"; // '11'

-: Subtraction

const newNumber = 1 - 1; // 0
const newString = "1" - "1"; // 0 - number-like strings are 'coerced' into numbers
const newString = "1" - "one"; // NaN (or 'Not-a-Number')

/: Division

const newNumber = 1 / 2; // 0.5
const newString = "1" / "2"; // 0.5
const newString = "1" / "two"; // NaN

*: Multiplication

const newNumber = 1 * 2; // 2
const newString = "1" * "2"; // 2
const newString = "1" * "two"; // NaN

%: Remainder (Modulo)

const newNumber = 2.3 % 1; // 0.3
const newString = "2.3" % "1"; // 0.3
const newString = "2.3" % "one"; // NaN

**: Exponentiation

const newNumber = 2 ** 3; // 8
const newString = "2" ** "3"; // 8
const newString = "2" ** "three"; // NaN

Relational

in: Object contains property (looking at keys only)

const hasSomething = "something" in { something: 1, another: 2 }; // true
const hasElephant = "something" in { something: 1, another: 2 }; // false
const hasOne = 1 in { something: 1, another: 2 }; // false

<: Less-than

const isSmall = 1 < 2; // true
const notSmall = 1 < 1; // false
const notSmall = 1 < 0; // false

<=: Less-than-or-equal-to

const isSmall = 1 <= 2; // true
const notSmall = 1 <= 1; // true
const notSmall = 1 <= 0; // false

>: Greater-than

const isSmall = 1 > 2; // false
const notSmall = 1 > 1; // false
const notSmall = 1 > 0; // true

>=: Greater-than-or-equal-to

const isSmall = 1 >= 2; // false
const notSmall = 1 >= 1; // true
const notSmall = 1 >= 0; // true

Equality

==: Equality (allowing coercion)

const notEqual = 1 == 2; // false
const equalNumbers = 1 == 1; // true
const similarString = 1 == "1"; // true
const similarBool = 1 == true; // true

!=: Inequality (allowing coercion)

const notEqual = 1 != 2; // true
const equalNumbers = 1 != 1; // false
const similarString = 1 != "1"; // false
const similarBool = 1 != true; // false

===: Identity (disallowing coercion)

const notEqual = 1 === 2; // false
const equalNumbers = 1 === 1; // true
const similarString = 1 === "1"; // false
const similarBool = 1 === true; // false

!==: Nonidentity (disallowing coercion)

const notEqual = 1 !== 2; // true
const equalNumbers = 1 !== 1; // false
const similarString = 1 !== "1"; // true
const similarBool = 1 !== true; // true

Logical

&&: Logical AND

const allTrue = true && true; // true
const someFalse = false && true; // false
const allFalse = false && false; // false

||: Logical OR (also a falsy-coalescing operator)

const allTrue = true || true; // true
const someFalse = false || true; // true
const allFalse = false || false; // false

// Falsy-Coalescing is used to return the first non-falsy value
const firstIsGood = "first" || "second"; // 'first'
const firstIsUndefined = undefined || "second"; // 'second'
const firstIsNull = null || "second"; // 'second'
const firstIsFalse = false || "second"; // 'second'
const firstIs0 = 0 || "second"; // 'second'

Assignment

=: Assignment

const a = 1; // 1
const b = a; // 1

*=: Multiplication assignment

const a = 2; // 2
const a *= 2; // 4 (a = a * 2)

/=: Division assignment

const a = 2; // 2
const a /= 2; // 1 (a = a / 2)

+=: Addition assignment

const a = 2; // 2
const a += 2; // 4 (a = a + 2)

-=: Subtraction assignment

const a = 2; // 2
const a -= 2; // 0 (a = a - 2)

[a, b] = [1, 2], {a, b} = {a: 1, b: 2}: Destructuring assignment

const anArray = [1, 2];
const anObject = { aKey: 1, bKey: 2 };
const [first, second] = anArray; // first = 1, second = 2
const { aKey } = anObject; // aKey = 1

,: Evaluate multiple, return last

const result = ((x = 1), (x += 2), (x /= 4), x); // 0.75

Miscellaneous

(condition ? ifTrue : ifFalse): ternary operator

const getFirst = 1 >= 0 ? "first" : "second"; // 'first'
const getSecond = 1 >= 2 ? "first" : "second"; // 'second'

?.: optional chaining operator

const something = {
  nullChild: null;
};
// Note: (`something.child` is `undefined`)
const undefinedChainOkay = something.child?.grandchild; // returns `undefined`
const undefinedChainError = something.child.grandchild; // throws error (trying to access `grandchild` of `undefined`)

const nullChainOkay = something.nullChild?.grandchild; // returns `undefined`
const nullChainError = something.nullChild.grandchild; // throws error (trying to access `grandchild` of `null`)

Docs: Statements

Mon, 01 Jan 0001 00:00:00 +0000

Declarations

let: Block-scoped variable

{
  let someVar;
  let someOtherVar = 10;

  {
    someVar = 20; // sub-scopes have access to variables from parent scope
    let subScopedVar = 40;
  }

  // subScopedVar => undefined, since it was defined in a child scope
}

const: Block-scoped constant

{
  const someVar; // NOT VALID, const variables must be assigned at declaration
  const someOtherVar = 10;

  {
    someOtherVar = 20; // NOT VALID, can't assign a value to a const variable
    const subScopedVar = 40;
  }

  // subScopedVar => undefined, since it was defined in a child scope
}

Flow control

try...catch: Handle errors

try {
  // do something 'risky'
} catch (error) {
  // gracefully handle error, return some default
}

if...else: Conditional

if (someCondition) {
  // do something
} else if (anotherCondition) {
  // do something else
} else {
  // just do this
}

switch: Conditional

switch (someInput) {
  case firstValue:
    // do something when `someInput === firstValue`
    break; // exits this switch-case and continue execution after the switch
  case secondValue:
  // do something when `someInput === secondValue`

  // without a `break` execution will "fall-through" to the next block even if
  // `someInput !== thirdValue`
  case thirdValue:
    // do something when `someInput === thirdValue` (or since there's no `break`
    // above, also `someInput === secondValue`)
    break;
  case fourthValue:
  case fifthValue:
    // do something when `someInput === fourthValue || someInput === fifthValue`
    return anotherValue; // can be used in place of break, this will return
  // `anotherValue` to the caller
  default:
    // do something if `someInput` hasn't matched any of the other cases
    break;
}

Iteration

for: standard for-loop

for (let i = 0; i < 9; i++) {
  // do something while `i` iterates through [0, 1, 2, 3, 4, 5, 6, 7, 8]

  if (someCondition) {
    break; // exit early if some `someCondition` happens
  }

  if (someOtherCondition) {
    continue; // stop executing this loop and start next iteration (don't execute MORE below)
  }

  /* MORE */
}

for...in: object property for-loop

const someObject = { first: 1, second: 2, third: "three" };
for (const key in someObject) {
  // do something while `key` iterates through ['first', 'second', 'third'] (order not guaranteed)
  const currentValue = someObject[key];

  if (someCondition) {
    break; // exit early if some `someCondition` happens
  }

  if (someOtherCondition) {
    continue; // stop executing this loop and start next iteration (don't execute MORE below)
  }

  /* MORE */
}

for...of: iterable for-loop

const someArray = ["a", "b", "c"];
for (const item of someArray) {
  // do something while `item` iterates through ['a', 'b', 'c']

  if (someCondition) {
    break; // exit early if some `someCondition` happens
  }

  if (someOtherCondition) {
    continue; // stop executing this loop and start next iteration (don't execute MORE below)
  }

  /* MORE */
}

while: while-loop

let done = false;
while (!done) {
  // do something

  if (someCondition) {
    break; // exit early if some `someCondition` happens
  }

  if (someOtherCondition) {
    continue; // stop executing this loop and start next iteration (don't execute MORE below)
  }

  /* MORE */

  if (finallyCondition) {
    done = true;
  }
}

do...while: do-while-loop (like a while-loop, except the body executes at least once)

let done = true;
do {
  // do something
  done = false;

  if (someCondition) {
    break; // exit early if some `someCondition` happens
  }

  if (someOtherCondition) {
    continue; // stop executing this loop and start next iteration (don't execute MORE below)
  }

  /* MORE */

  if (finallyCondition) {
    done = true;
  }
} while (!done);

Docs: Standard Objects

Mon, 01 Jan 0001 00:00:00 +0000

The following JavaScript standard objects are available for use in Calculations and Alerts.

Values

Infinity: Numeric property representing infinity

const a = Infinity;
const b = -Infinity;

return a === Infinity; // true

NaN: Property representing something that is not a number

const a = 1 - "string"; // NaN

return a === NaN; // true

undefined: Property representing something that is not defined

const someObject = { a: 1, b: 2 };

return someObject.c === undefined; // true

Functions

isFinite: Check if number is not Infinity

isFinite(Infinity); // false
isFinite(-Infinity); // false
isFinite(10 / 0); // false (divide by zero)
isFinite(42); // true
isFinite("abc"); // false

isNaN: Check if value is Not-A-Number

isNaN(1 - "string"); // true
isNaN(-Infinity); // false ... debatable
isNaN(42); // false
isNaN("abc"); // true

parseFloat: Parse a number from a string as a float

parseFloat("1.234"); // 1.234
parseFloat("1"); // 1.0
parseFloat("a1"); // NaN

parseInt: Parse a number from a string as an integer

parseFloat("1.234"); // 1
parseFloat("1"); // 1
parseFloat("a1"); // NaN

decodeURI: Decode a URI encoded string

const encoded = "%7B%22a%22:1,%20%22b%22:2%7D";
decodeURI(encoded); // {"a":1, "b":2}

encodeURI: Encode a string for URI

const raw = '{"a":1, "b":2}';
encodeURI(raw); // %7B%22a%22:1,%20%22b%22:2%7D

Fundamentals

Error: The standard Error Object in JavaScript

try {
  const e = new Error("Im an Error");

  // Properties & Methods
  e.name; // 'Error'
  e.message; // 'Im an Error'
  e.toString(); // 'Error: Im an Error'

  throw e;
} catch (error) {
  console.log(error); // 'Error: Im an Error'
}

Numbers & Dates

Number: Wrapper Object for a number

const a = 123; // 123
const b = Number("123"); // returns the number 123
a === b; // true

Number("unicorn"); // NaN
Number(undefined); // NaN

// Properties & Methods
const c = 123.456789;
c.toExponential(3); // '1.235e+2'
c.toFixed(2); // 123.46
c.toPrecision(4); // 123.4
c.toString(); // '123.456789'

BigInt: Wrapper Object for integers larger than can be stored in Number

const a = 1n; // 1, note the `n` in the literal specifies this is a **BigInt**

a === 1; // false
a == 1; // true
a < 3; // true
a > 0; // true
// ... relational comparison to Number works intuitively

const b = BigInt(Number.MAX_SAFE_INTEGER); // 9007199254740991n
b * 2n; // 18014398509481982n

// Properties & Methods
const c = 123n;
c.toString(); // '123'

Date: Represents a date object. Fundamentally represented as an integer of the number of milliseconds since January 1, 1970 00:00:00 UTC

const a = Date.now(); // 1607096922047, number of milliseconds from 1/1/1970 to
// the time the statement executes
Date.parse("2020-12-04T15:52:32.939Z"); // returns a Date object for the time
// specified by the input string

new Date(); // Date object representing 'now';
new Date(value); // Date object for the milliseconds `value`
new Date(dateString); // Date object by parsing `dateString`
new Date(year, monthIndex, day, hours, minutes, seconds, milliseconds); // Date object by specifying elements
/* | -- optional -----------------------------| */

b = new Date(); // Date: 2020-12-04T15:59:00.946Z
b.getTime(); // 1607097540946
b.getUTCDate(); // 4 (day of the month 1-31)
b.getUTCDay(); // 5 (day of the week 0-6)
b.getUTCFullYear(); // 2020
b.getUTCHours(); // 15
b.getUTCMilliseconds(); // 946
b.getUTCMinutes(); // 59
b.getUTCMonth(); // 11 (month of the year 0-11)
b.getUTCSeconds(); // 0
b.toUTCString(); // 'Fri, 04 Dec 2020 15:59:00 GMT'
b.toString(); // 'Fri Dec 04 2020 09:59:00 GMT-0600 (Central Standard Time)'
b.toISOString(); // '2020-12-04T15:59:00.946Z'
b.toDateString(); // 'Fri Dec 04 2020'
b.toTimeString(); // '09:59:00 GMT-0600 (Central Standard Time)'

… plus many more: see Mozilla: Date

Math: Collection of mathematical properties and methods (works with Number, but not BitInt)

// Constants
Math.E; // Euler's constant and the base of natural logarithms; approximately 2.718.
Math.PI; // Ratio of the a circle's circumference to its diameter; approximately 3.14159.

// Functions
Math.abs(x); // Returns the absolute value of x.
Math.ceil(x); // Returns the smallest integer greater than or equal to x.
Math.floor(x); //Returns the largest integer less than or equal to x.
Math.round(x); // Returns the value of the number x rounded to the nearest integer.

Math.sin(x); // Returns the sine of x.
Math.cos(x); // Returns the cosine of x.
Math.tan(x); // Returns the tangent of x.
Math.asin(x); // Returns the arcsine of x.
Math.acos(x); // Returns the arccosine of x.
Math.atan(x); // Returns the arctangent of x.
Math.atan2(y, x); // Returns the arctangent of the quotient of its arguments.

Math.exp(x); // Returns Ex, where x is the argument, and E is Euler's constant (2.718…, the base of the natural logarithm).
Math.log(x); //Returns the natural logarithm (ln) of x.
Math.log10(x); //Returns the base-10 logarithm of x.
Math.log2(x); //Returns the base-2 logarithm of x.

Math.max(x, ...); //Returns the largest of zero or more numbers.
Math.min(x, ...); //Returns the smallest of zero or more numbers.

Math.pow(x, y); //Returns base x to the exponent power y (that is, xy).
Math.sqrt(x); // Returns the positive square root of x.

Math.sign(x); // Returns the sign of the x, indicating whether x is positive, negative, or zero.

Math.random(); // Returns a pseudo-random number between 0 and 1.

… plus many more: see Mozilla: Math

Text

String: Wrapper Object for a string

const a = "A string   ";
const b = "A string using double quotes";
const typeOfQuotes = "back-tick";
const c = `A format string using ${typeOfQuotes} quotes`; // 'A format string using back-tick quotes'
const d = new String("Another string"); // 'Another string'

a.length; // 8
a.charAt(3); // 't'
a.charCodeAt(3); // 116
a.includes("str"); // true
a.startsWith("A "); // true
a.endsWith("ing"); // false
a.indexOf("str"); // 2
a.indexOf("who"); // -1

// Return a new string ... (doesn't modify `a`)
a.toLowerCase(); // a string
a.toUpperCase(); // A STRING
a.replace("ing", "ong"); // 'A strong   '
a.concat("with some more string"); // 'A string   with some more string'
a.repeat(4); // 'A string   A string   A string   A string   '
a.trim(); // 'A string'
a.trimStart(); // 'A string   '
a.trimEnd(); // 'A string'
a.split(" "); // [ 'A', 'string', '', '', '' ]

Indexed Collections

Array: Array of JavaScript elements

const items = ['a', 'b', 3];
const items2 = new Array(); // []
const items3 = new Array(5); // [ undefined, undefined, undefined, undefined, undefined ]

items[0]; // 'a'
Array.isArray(items); // true
Array.isArray('a'); // false

const newArray = items.concat([4, 5, 'f']); // ['a', 'b', 3, 4, 5, 'f']

newArray.every((item) => typeof item === 'string'); // false
newArray.forEach((item) => /* do something */); // returns void
newArray.map((item) => /* do something */); // returns an array with each result of `do something`

newArray.includes('b'); // true
newArray.includes('c'); // false
newArray.indexOf('b'); // 1
newArray.indexOf('c'); // -1
newArray.find((item) => item === 'b'); // 'b'
newArray.find((item) => item === 'c'); // undefined
newArray.find((item) => item > 3); // 4
newArray.findIndex((item) => item === 'b'); // 1
newArray.findIndex((item) => item === 'c'); // -1
newArray.findIndex((item) => item > 3); // 3

newArray.join(':'); // 'a:b:3:4:5:f'

const lastElement = newArray.pop(); // 'f', newArray = ['a', 'b', 3, 4, 5]
newArray.push('g'); // ['a', 'b', 3, 4, 5, 'g']

const firstElement = newArray.shift(); // 'a', newArray = ['b', 3, 4, 5, 'g']
newArray.unshift(1); // [1, 'b', 3, 4, 5, 'g']

const subArray = newArray.slice(2, 4); // [3, 4] from index 2 to less than 4 (newArray is unmodified)

const deletedElements = newArray.splice(2, 4); // [3, 4, 5, 'g'] from index 2 delete 4 elements (newArray = [1, 'b'])
const noDeletedElements = newArray.splice(2, 0, 'c', 'd', 'e'); // [] from index 2 delete 0 elements, then insert 'c', 'd', 'e' (newArray = [1, 'b', 'c', 'd', 'e'])

newArray.toString(); // '1,b,c,d,e'

newArray.reverse(); // [ 'e', 'd', 'c', 'b', 1 ] (newArray = [ 'e', 'd', 'c', 'b', 1 ])

… plus many more: see Mozilla: Array

The following typed Arrays are also available: Int8Array, Uint8Array, Uint8ClampedArray, Int16Array, Uint16Array, Int32Array, Uint32Array, Float32Array, Float64Array, BigInt64Array, and BigUint64Array

Keyed Collections

Map: See Mozilla Map
Set: See Mozilla Set
WeakMap: See Mozilla WeakMap
WeakSet: See Mozilla WeakSet

Miscellaneous

JSON: serialize / deserialize JSON

JSON.parse('{"a":1, "b": 2}'); // {a:1, b: 2}
JSON.stringify({ first: "first", second: "second" }); // '{"first":"first","second":"second"}'
JSON.stringify(["a", "b", "c"]); // '["a","b","c"]'

Docs: Delay

Mon, 01 Jan 0001 00:00:00 +0000

Available Functions

`samples(signal, delay, initial)`

Delay a signal by some amount of “samples”

Usage

core.delay.samples(signal, delay);
core.delay.samples(signal, delay, initial);

Arguments

signal: [any] raw value
delay: [number] number of samples to delay the output
initial: [any] (optional) value to use for the first delay seconds (defaults to first received value)

`time(signal, delay, initial)`

Delay a signal by some amount of time

Usage

core.delay.time(signal, delay);
core.delay.time(signal, delay, initial);

Arguments

signal: [any] raw value
delay: [number] time, in seconds, to delay the output
initial: [any] (optional) value to use for the first delay seconds (defaults to first received value)

`timeToTrue(signal, delay)`

Delay the rising edge of a signal for delay seconds. Falling edges are passed through without delay. The output takes the value of the input after delay seconds from the last rising edge. So if the input is false at delay seconds, the output stays false.

Usage

core.delay.timeToTrue(signal, delay);

Arguments

signal: [boolean] raw value
delay: [number] time, in seconds, to delay the output rising edge

`timeToFalse(signal, delay)`

Delay the falling edge of a signal for delay seconds. Rising edges are passed through without delay. The output takes the value of the input after delay seconds from the last rising edge. So if the input is true at delay seconds, the output stays true.

Usage

core.delay.timeToFalse(signal, delay);

Arguments

signal: [boolean] raw value
delay: [number] time, in seconds, to delay the output falling edge

Docs: Filter

Mon, 01 Jan 0001 00:00:00 +0000

Available Functions

`firstOrderLag(signal, tau)`

Filter a signal using a first-order low-pass filter.

Usage

core.filter.firstOrderLag(signal, tau);

Arguments

signal: [number] unfiltered value
tau: [number] time-constant. Large values result in more filtering.

Effect of tau on time-response

Docs: Logic

Mon, 01 Jan 0001 00:00:00 +0000

Available Functions

`latchROS(set, reset)`

Latch output to true when the set argument is true. Reset the output to false when reset is true. Prioritize reset over set if both inputs are true.

Usage

core.logic.latchROS(set, reset);

Arguments

set: [boolean] latches the output to true
reset: [boolean] resets the output to false regardless of the value of set

`latchSOR(set, reset)`

Latch output to true when the set argument is true. Reset the output to false when reset is true. Prioritize set over reset if both inputs are true.

Usage

core.logic.latchROS(set, reset);

Arguments

set: [boolean] latches the output to true
reset: [boolean] resets the output to false only if set is false

Docs: State

Mon, 01 Jan 0001 00:00:00 +0000

Core Concepts

For more information on the core concepts surrounding the usage of state machines see State Machine Concepts.

State Machine Editor

In the 1.10 Release, a new State Machine Editor was introduced. With this editor, creating state machines is now even easier and all of the scripting below is generated by the GUI editor. See State Machine Editor. The following page is primarily useful only if you’re manually reviewing the state-machine created with the new editor.

Conceptual Components Applied

Machines

Machines are created using core.state.createMachine(), which returns a Machine Object. Refer to the Machine Class Definition for more details on the available methods. When referring to a machine in other calculations and alerts (e.g. calculation.myStateMachine), the returned value will be the string representation of the active state using dot-notation for the current active hierarchy (e.g. 'B.A.B').

States

States are added to a Machine prior to initialization(). The encapsulate a set of Actions and Transitions. The current active state can be accessed by referencing the state-machine directly in other calculations and alerts (e.g. calculation.myStateMachine).

Actions

Actions are be evaluated at state-entry, during-state-execution, and at state-exit. Actions define an arbitrary set of logic to be evaluated at the specified time.

For more information see:

The primary use-case for actions will likely be to update the state-machine’s local variables. Every State-Action is passed 3 positional arguments when evaluated: local, event, and state (see StateAction for more details on the contents of these arguments).

Transitions

Transition conditions are evaluated at the start of each “step” while the From-State is active. Transitions can be added between states with the .addTransition(from, to, options) function. Users can optionally define a condition in which to take the transition. If a condition isn’t specified, the transition is automatically taken on the “step” after the From-State becomes active. It is also possible to define TransitionActions which are evaluated when a transition is evaluated, however it is recommended to use StateActions unless TransitionAction is the only way to satisfy the requirement.

Simple Applied Example

For this example, we’ll create the following state-machine:

Simple State-Machine Example

The calculated field for the myStateMachineCalculation calculation:

// #region initialize
core.state
  .createMachine()
  .addState("High")
  .addState("Low", { initial: true })
  .addState("High.Transitioning", { initial: true })
  .addState("High.Active")
  .addTransition("High", "Low", {
    condition: (local, event, state) => local.input1 < 6,
  })
  .addTransition("Low", "High", {
    condition: (local, event, state) => local.input1 > 10,
  })
  .addTransition("High.Transitioning", "High.Active", {
    condition: (local, event, state) => after(local.transitionTimeSec, "sec"),
  })
  .addDuringAction("Low", (local, event, state) => local.lowStepCount++)
  .addEntryAction(
    "High",
    (local, event, state) => (local.highEntryTime = new Date())
  )
  .addExitAction(
    "High",
    (local, event, state) =>
      (local.highDuration =
        new Date().getTime() - local.highEntryTime.getTime())
  )
  .withLocal({
    transitionTimeSec: 10,
    input1: sensor.sensorA,
    input2: calculation.otherCalculation,
  })
  .initialize();
// #endregion initialize

// #region step
core.state.stepMachine({
  local: {
    input1: sensor.sensorA,
    input2: calculation.otherCalculation,
    otherMachineState: calculation.otherMachine, // this will be the string-value of the active state in the "otherMachine" state-machine
    otherMachineInternalVariable: core.state.getLocal(
      "otherMachine",
      "otherMachineInternalVariable"
    ),
  },
});
// #endregion step

withLocal is used to set any local variables which may be required during initialization or isn’t updated during stepMachine.

Example 1: the machine has an Action on an initial transition which reads a local variable withLocal.

Example 2: the machine has local variables which are “constant” and aren’t updated as part of stepMachine.

The internal variable highDuration can be accessed in other calculations / alerts by using the following:

core.state.getLocal("myStateMachineCalculation", "highDuration");

Available Functions

`createMachine()`

Create a new state machine.

This machine is created using the name of the calculation to which it is assigned to (e.g. if calculation.myStateMachine = core.state.createMachine() ..., the machine will be named myStateMachine, see core.state.getLocal)

Usage

core.machine.createMachine();

Arguments

None

`stepMachine(options)`

Step the machine using the options provided.

Usage

core.state.stepMachine({
  local: {
    variableA: 1,
    variableB: sensor.sensorA,
  },
  event: {
    timestamp: new Date("2021-09-07T19:20:24.611Z"),
    type: "MY_SUPER_EVENT",
  },
});

Arguments

options: [dictionary] dictionary with the following fields:

local: [dictionary] key:values to update the machine local variables
event: [Event] an event definition for event-driven state-machines

`getLocal(machine, variable)`

Retrieve data from the local variables of a state-machine.

Usage

core.state.getLocal("myStateMachine", "variableA");

Arguments

machine: [string] the name of the machine to fetch data from (i.e. the calculation name)
variable: [string] the name of the local variable to fetch

Available Condition Functions

`after(count, unit)`

Evaluates to true after the specified time since the current state has been activated.

Usage

.addTransition('from', 'to', {condition: (local, event, state) => after(10, 'sec')})

Arguments

count: [number] the number of units to wait before returning true
unit: [‘min’ | ‘sec’ | ‘msec’] (default: ‘sec’) the time-unit of count

`afterEvent(count, unit, event)`

Evaluates to true after the specified time since the specified event was last received.

Usage

.addTransition('from', 'to', {condition: (local, event, state) => afterEvent(10, 'sec', 'MY_EVENT_NAME')})

Arguments

count: [number] the number of units to wait before returning true
unit: [‘min’ | ‘sec’ | ‘msec’] (default: ‘sec’) the time-unit of count
event: [string] the name of the event to trigger on

Available Classes

`Machine`

The primary state-machine class used to track and manage a given state machine.

Usage

const myMachine = new Machine(name, options);

Arguments

name: [string] the name of the state-machine
options: [dictionary] with the following fields:

parallel [boolean] if the top-level states are parallel states (default: false)
currentTime [Date] the initial time used within the machine

`Machine.withLocal(variables)`

Fully override the state-machine’s local variables with that provided.

Usage

myMachine.withLocal({
  variableA: 1,
  variableB: 2,
});

Arguments

variables: [dictionary] key:values to update the machine local variables

`Machine.setLocal(variables)`

Override specific keys within a state-machine’s local variables.

Usage

myMachine.setLocal({
  variableA: 3,
});

Arguments

variables: [dictionary] key:values to update the machine local variables

`Machine.addState(name, options)`

Add a state to the state-machine.

Usage

myMachine
  .addState("State1", { initial: true })
  .addState("State1.ChildA", {
    initial: true,
    initialTransitionActions: (local, event, state) => {
      local.variableA = 0;
    },
  })
  .addState("State1.ChildB");

Arguments

name: [string] the fully qualified name of the state (using dot-notation (.) for nested states) options; [dictionary] dictionary with the following fields:

initial: [boolean] determines if the state is the initial when it’s parent becomes active (from inactive)
initialTransitionActions: [TransitionAction | Array<TransitionAction>] the action(s) to execute when the initial-transition is taken

`Machine.addEntryAction(stateName, action)`

`Machine.addDuringAction(stateName, action)`

`Machine.addExitAction(stateName, action)`

`Machine.addTransition(from, to, options)`

Add a transition to the state-machine.

Usage

myMachine.addTransition("State1.ChildA", "State1.ChildB", {
  condition: (local, event, state) => event.type === "MY_SUPER_EVENT",
});

Arguments

from: [string] the fully qualified name of the from-state
to: [string] the fully qualified name of the to-state
options: [dictionary] dictionary with the following fields:

condition: [Condition] The condition on which to take the transition
actions: [TransitionAction | Array<TransitionAction>] the action(s) to execute when the initial-transition is taken
priority: [number] the order in which this transition-condition is evaluated with respect to all transitions out of the active state

`Machine.initialize()`

Initialize a state-machine.

Usage

myMachine.initialize();

Arguments

None

Available Types

`StateAction`

A callable function to evaluate during one of the 3 execution phases of a state.

Interface

(local, event, state) => Promise<void> | void

Arguments

local: the current local-variables of the state-machine are passed into this positional argument at evaluation
event: the active event (if any) of the state-machine is passed into this positional argument at evaluation
state: [dictionary] with the following fields:

stepCount: [number] represents the total steps taken since the entry of into the active state
entryTime: [Date] represents the machine-time in which the state was activated
currentTime: [Date] represents the current machine-time
events: [dictionary] key:values with keys representing all events which have occurred during the current state and their EventStats

`TransitionAction`

A callable function to evaluate during the execution of the transition.

Interface

(local, event) => Promise<void> | void

Arguments

local: the current local-variables of the state-machine are passed into this positional argument at evaluation
event: the active event (if any) of the state-machine is passed into this positional argument at evaluation

`Condition`

A callable function to evaluate to determine if a condition is true or false.

Interface

(local, event, state) => Promise<boolean> | boolean;

Arguments

same as StateAction

`Event`

An interface defining a Machine Event

Interface

interface Event {
  timestamp: Date;
  type: string;
}

`EventStats`

An interface defining statistics of a given Event

Interface

interface Event {
  latestTimestamp: Date;
  count: number;
}

Docs: Digital Twin

Mon, 01 Jan 0001 00:00:00 +0000

To reference data from other IoT Connected Assets from a given IoT Connected Asset’s calculations and alerts, the following keys provide a way of traversing your Digital Twin hierarchy. From any of the following keys, you can define a role-path to the role which you are interested in.

Available Keys

`$self`

Retrieve a reference to another component with respect to “myself”.

Usage

// Get Reference to My Child's Child
$self.child_A.childs_child;

// Get Reference to My Child's Child
// **Note** this is illustrative only, as you can access sensors /
// calculations / directly without this
$self;

// Use reference to access the aggregated value of `sensorA`
$self.child_A.childs_child.sensor.sensorA;

`$parent`

Retrieve a reference to another component with respect to “my parent”.

Usage

// Get Reference to My Sibling
$parent.sibling_A;

// Get Reference to My Parent directly
$parent;

// Use reference to access the aggregated value of `sensorA`
$parent.sibling_A.sensor.sensorA;

`$root`

Retrieve a reference to another component with respect to “my top-level root”.

Usage

// Get Reference to My Family Member
$root.someRole.subassembly;

// Get Reference to My Root directly
$root;

// Use reference to access the aggregated value of `sensorA`
$root.someRole.subassembly.sensor.sensorA;

`$context`

Retrieve a reference to another component by referencing an External ID defined in a Context Field. When using the $context key, you must supply a context field name. Formula processing will assume the referenced field is the External ID to another IoT Connected Asset and attempt to access its data.

Usage

// Get Reference to an arbitrary IoT Connected Asset's child
$context.contextFieldName.child_A;

// Get Reference to an arbitrary IoT Connected Asset directly
$context.contextFieldName;

// Use reference to access the aggregated value of `sensorA`
$context.contextFieldName.sensor.sensorA;

Examples

Digital Twin Definition

Let’s assume we have the following Digital Twin Role Hierarchy:

(role : thingType)
bike : Bicycle
  ├ rearWheel : Wheel
  │   ├ brake : Brake
  │   └ tire : Tire
  │
  ├ frontWheel : Wheel
  │   ├ brake : Brake
  │   └ tire : Tire
  │
  └ bottomBracket : BottomBracket
      ├ crank : Crank
      ├ bearing : Bearing
      ├ leftPedal : Pedal
      └ rightPedal : Pedal

Digital Twin Instantiation

Let’s then assume the following instance of this Digital Twin:

(externalID : role)
BIKE001 : bike
  ├ WHEEL001 : rearWheel
  |   ├ BRAKE001 : brake
  |   └ TIRE001 : tire
  |
  ├ WHEEL002 : frontWheel
  |   ├ BRAKE002 : brake
  |   └ TIRE002 : tire
  |
  └ BRACKET001 : bottomBracket
      ├ CRANK001 : crank
      ├ BEARING001 : bearing
      ├ PEDAL001 : leftPedal
      └ PEDAL002 : rightPedal

Referencing Data

On the Bicycle thing type let’s write the formula for a Calculation named tirePressureDifference:

$self.frontWheel.tire.sensor.pressure - $self.rearWheel.tire.sensor.pressure;

Then in the Tire Thing Type (which will execute for each tire) let’s add the following formula for an Alert named tirePressureAbnormal:

if ($root.calculation.tirePressureDifference > 10) {
  // if parent is 'rearWheel', sibling is 'frontWheel' else sibling is 'rearWheel'
  const siblingPressure =
    $parent.twin.role === "rearWheel"
      ? $root.frontWheel.sensor.pressure
      : $root.rearWheel.sensor.pressure;

  // check if I'm the "low" one
  return sensor.pressure < siblingPressure;
} else {
  return false;
}

Some further examples of traversing this Digital Twin:

From PEDAL001

$parent; // BRACKET001

$parent.bearing; // BEARING001

$parent.$parent.frontWheel; // WHEEL002

$root.frontWheel; // WHEEL002

From WHEEL002

$root.bottomBracket; // BRACKET001

$self.tire; // TIRE002

Docs: State Machines

Mon, 01 Jan 0001 00:00:00 +0000

Components

Machines

A collection of States, Transitions and Actions. At the end of any given step each serial-sub-state within a machine will contain exactly one active state.

States

A state encapsulates a set of logic to be evaluated when active. States can be hierarchical. A parent state is active if any of its child-states are active. Each state has three phases of execution, entry, during, and exit. When a State changes from inactive to active, its entry actions are evaluated. When a State starts active and ends active (in a given step), its during actions are evaluated. When a State changes from active to inactive, its exit actions are evaluated.

Actions

Actions define processing within various scopes. Actions can be used to update the Machine local variables, set global variables, or make call-outs to external web services.

Transitions

The Transition defines a path between two states, the From-State and the To-State. Once a transition is executed, the From-State becomes inactive and the To-State becomes active. Transitions can include Actions which are evaluated once the transition is executed

Events

An alternate input-scheme which can be used instead-of or alongside local variables. Events can be useful if your approach includes combining several calculations ahead of evaluating the state-machine. The catch is that only a single Event can be handled by the state-machine for any given step.

Execution

State Machine Execution

Initialization

Once a Machine is created, it will sit in an uninitialized state, whereby no state is active and no transitions have been evaluated. If the first call to myMachine.step() happens before the machine is initialized, it will automatically initialize the Machine. It’s best practice to explicitly initialize the Machine, once construction is complete by calling myMachine.initialize().

During initialization, at each level in the hierarchy, the initial state is determined during construction by explicitly specifying {initial: true} in the desired state

if two states at the same level are specified as initial, the last one specified wins

From the top of the hierarchy down, each initial-transition is identified and evaluated. The machine is fully initialized once every state has the appropriate number of active states as defined by it’s Decomposition (serial vs parallel).

Step

Once a Machine is initialized, it can be “stepped” through time. Each step represents a discrete point in time (in our specific case, the machine is “stepped” upon receipt of each IoT Message).

During the step, all Transitions from the active state hierarchy are evaluated from the top, down. That is to say, given active state, B.B.B, all Transitions out of the top state B are evaluated in priority order, executing the first Transition who’s condition expression evaluates to true or who’s condition doesn’t exists (i.e. an Unconditional Transition). If no Transitions at level B are to be executed, all Transitions at the B.B level are evaluated in the same manor until either a Transition is identified to evaluate, or no Transitions are to be taken.

If a Transition is identified to evaluate, first the exit actions in the lowest level From-State are evaluated, then the exit actions are evaluated up the hierarchy until the lowest-common State between From-State and To-State. Meaning in a transition from B.B.B to B.B.A, only the exit actions from B.B.B are evaluated (since B.B is never exited during the transition). Whereas if transitioning from B.B.B to A.B, the exit actions at B.B.B, B.B, and B are evaluated.

If no Transitions are to be evaluated, the during actions of the current active state are evaluated from the top, down.

Examples

Full Example

Illustrative (not functional) State Machine containing all possible features of the State Machine library.

Initialization:

The initial transition into B is evaluated and the local variable, time0 is set to now.
B is activated.
B entry actions are evaluated, incrementing the machine variable, bEntry
States B.A and B.B run in parallel (indicated by the dashed border). B.A and B.B are activated.
So, the initial transitions into B.A.B and B.B.B are executed.
Both B.A.B and B.B.B are activated.

Step 1:

Both B.A.B and B.B.B are active.
First there exists a transition at the top level, somethingElse < 50. If this evaluates to true, then all active children of B are exited and deactivated from the bottom up. For this example let’s assume somethingElse = 100, so this transition will not be executed.
Since the transition from B.B.B to B.B.A is unconditional, it is marked for evaluation.
B.B.B exit actions are evaluated (local variable, bbbExit is incremented)
B.B.B is deactivated
If there were any actions defined on this transition, they’d be evaluated here.
B.B.A is activated
B.B.A entry actions are evaluated (local variable, bba is now true)
B during actions are evaluated (bDuring is incremented)

Step 2:

Both B.A.B and B.B.A are active.
There are two transitions out of B.B.A (priority can be set on transitions to handle this case). If something < 10, then transition 1 would be marked for evaluation, otherwise, transition 2 is unconditional, so it will be marked for evaluation by default. For this example, let’s say something = 6, so transition 1 is marked for evaluation.
B.B.A is deactivated
B.A.B is deactivated
B.A is deactivated
B.B is deactivated
B.B exit actions are evaluated (bbExit is incremented)
B is deactivated
If there were any actions defined on this transition, they’d be evaluated here.
A is activated
A.A is activated

Advanced Topics

State-Decomposition

At any given level in the state-hierarchy, there are two possible modes of execution: Serial (default) and Parallel. Serial decomposition defines that at a given level, there is only ever a single active state at the end of any give step. Contrary, Parallel decomposition defines that all states at a given level are active. In the examples below, the Serial State Machine will only ever have a single active state (e.g. 'A.B' or 'B.A.B'), whereas the Parallel State Machine will have 3 active states at any given time (e.g. ['A.A', 'B.A.B', 'B.B.A'] etc.)

Serial State Machine

Parallel State Machine

Docs: Salesforce Mobile

Thu, 01 Jul 2021 00:00:00 +0000

We’ve built full a parity of features into the Salesforce Mobile App components as with our Salesforce Desktop / Lightning experience. A few items will look slightly different due to form factor, but all the functionality is available in the mobile app.

IoT Console (Mobile)

The IoT Console search works identically, just scroll down after searching to see your results either in the map or data tabs.

Salesforce Mobile - IoT Console

The map is fully interactive, just look on the desktop.
Click on a map pin to see the detail popup.
When in the data view, you’ll notice the results are returned as “cards” instead of a table to render nicely in a small form factor. - All the same data and functionality is available.

Thing Components (Mobile)

When you click into a Thing (Asset), the same Lightning Components are available, including the IoT Thing Details and Thing Command…

Salesforce Mobile - Thing Components

All Thing Details functionality is available, including Register, Sync Context & Manual Sensor Entry
The fully interactive IoT Thing Data and Snapshots component is also available.
The Digital Twin diagram and editor is also available.

Docs: ServiceNow Mobile Agent

Thu, 01 Jul 2021 00:00:00 +0000

We’ve built features from our ServiceNow Desktop Application into the ServiceNow Mobile Agent App.

There are three navigation tabs in the Mobile Agent App. They are All Connected Assets, All Alert Histories,and All Asset Attributes. These tabs enable you to view their respecive lists in the Mobile App. Record Cards can be tapped to view more information about each record.

Mobile Agent All Connected Assets Tab

On the All Connected Assets tab, each record has two additional actions. You can swipe left and right on each record to display additional actions related to each record. Sliding Right reveals buttons to navigate to two related lists. These lists are the Alert Histories and the Asset Attributes for the record.

Sliding Right on Records

Sliding left reveals buttons to open the IoT Copilot chat, the Thing Chart, and the Digital Twin.

Sliding Left on Records

The following Mobile Components can do everything the Desktop variantes can do except for attaching chart or digital twin data to the IoT Copilot.

Mobile IoT Copilot

Movile IoT Copilot Display

Mobile Thing Chart

Mobile Thing Chart Display

Mobile Digital Twin

Mobile Digital Twin Display Part 1

Mobile Digital Twin Display Part 2

Docs: Release 6.1 (Winter '26)

Mon, 29 Dec 2025 00:00:00 +0000

New Features:

IoT Copilot Insights The new IoT Copilot feature improves on the way you interact with connected assets in Bolt Data Connect.
- Using natural language in a chat window, you can ask questions about an asset’s performance based on IoT telemetry data and alert history, unlocking instant insights.
- Each Thing Type can also define natural-language IoT Copilot Instructions, to provide context and insight.
- Ask Copilot about Digital Twin or Thing Chart data views with a single click!

IoT Copilot

Data Lake Calculations Gain insights into your IoT Data Lake by defining Data Lake Calculations for each of your Thing Types. By simply selecting the Frequency(s) and desired Metrics, the IoT Cloud will then calculate and synchronize the metrics values into the “IoT Sensor Data” records. These new Data Lake Calculation metrics values are also available in Reports and Dashboards.

Data Lake Calculations Editor

Improved Simulators New Salesforce Based Simulators provide a more convenient, stable framework for running Simulators.
- Salesforce Hosted: Running in Salesforce ensures reliability and stability, with the same easy-to-use user interface, saving time and reducing complexity.
- Copy between Orgs: Since the Simulator Config and setup is saved as Custom Metadata and Settings, it’s easy to copy or deploy between sandboxes.

Salesforce Based Simulators

Docs: Release 5.1 (Winter '25)

Mon, 27 Jan 2025 00:00:00 +0000

New Features:

Connected Asset Agent The new Connected Asset Agent feature revolutionizes the way you interact with connected assets in Bolt Data Connect. Using natural language in a chat window, you can ask questions about an asset’s performance based on IoT telemetry data and alert history, unlocking instant insights.
- NOTE: For Salesforce orgs using Agentforce, the Connected Asset Agent integrates easily via Agentforce Actions. This integration enables users to access real-time insights on asset performance directly within Agentforce, providing a richer user experience.

Connected Asset Agent

Change Management Tools Managing assets is now even easier with significant upgrades to the Change Management features in Bolt Data Connect. These improvements provide enhanced clarity, stability, and efficiency in tracking changes and deploying assets. They also streamline the syncing of Thing Type setups and configurations, making deployments faster and simpler.
- Simplified Deployments to Production: The deployment process from sandbox to production environments is now more intuitive with a simplified user interface, saving time and reducing complexity.
- Batch Syncing for Improved Efficiency: Previously, each Thing Type needed to be synced individually. Now, with just a single click, multiple Thing Types can be synced from Salesforce to the IoT Cloud at once, reducing sync time.
- Comprehensive Audit Trail: Access, compare and restore to historical versions of your setups and configurations. This feature helps you debug issues and identify what changes have recently been made for full transparency.

Enhanced Change Management Tools

Automatic Geo-Coding Managing a large number of assets requires precise location tracking. With this release, assets are automatically geo-coded with latitude and longitude coordinates, calculated using the Address fields on the Salesforce objects. This eliminates the need to manually look up coordinates for individual asset locations, saving time and enabling admins to maximize the map view in the IoT Console for all assets.

Automatic Geo-Coding

Sensor Gauges This NEW lightning web component allows Customers to easily create a custom Screen Flow and render whichever sensor values they want to as Gauges or Progress Bars/Rings.

Sensor Gauges

Docs: Release 4.4 (Summer '24)

Sun, 08 Sep 2024 00:00:00 +0000

New Features:

Machine Learning (AI/ML) Define Machine Learning (ML) Models and Inferences that will be executed in the IoT Cloud. The resulting ML Inferences are available in the Calculated Fields, Alert Conditions, Visualizations and the IoT Database and Data Lake.
- Create/Upload ML Models Any ML Model can be created by a data-scientist and uploaded the IoT Cloud (e.g. Anomaly Detection, Value Predictions, etc.)
- Define ML Inferences in Thing Types in IoT Setup

ML Models and Inferences

Enhanced Auto-Registration NEW IoT Registration records can now be auto-created by the IoT Cloud as unrecognized IoT Things are detected, or created in Salesforce by an integration. The Auto-Registration job can also be configured and scheduled to automatically find, populate, and register/deregister the related IoT Things.

Auto-Registration Setup

Language Translations Added support for Translations to all of the Visualizations and end-user components as well as multiple out-of-the-box Language Translations.

Language Translations

Thing Timeline The NEW Thing Timeline component can be added to the Thing/Asset page to show important events including:
- IoT Registrations
- IoT Alert History
- Asset Downtime Periods
- Cases & Work Orders
- Servitization Coverage

Thing Timeline

License Alarms License Alarms can now be configured and automatically created into Salesforce so that administrators can monitor and automate actions on both Salesforce App and Device Licenses.

License Alarms

Docs: Release 4.1 (Winter '24)

Wed, 01 Nov 2023 00:00:00 +0000

New Features:

Visual Twin Editor Drag-and-drop image selector / editor where the admin can assign an image to each Thing Type and annotate shapes on the image for binding the Sensors, Calculated Fields, and Alert Conditions.

Visual Twin Editor

Visual Twin Viewer View & interact with the configured Visual Twin, including:
- Visual Twin Timeline: The history of points-in-time are available to review / compare values, with easy navigation using arrow-keys and support for both in-memory values and snapshots.
- Visual Twin Snapshots: Any Visual Twin point-in-time can be saved to Salesforce as an IoT Data Snapshot record. These snapshots are loaded in the viewer on the timeline for reviewing / comparison.
- Visual Twin Streaming: The ability to subscribe to the IoT stream of data is also available, allowing the user to view the latest values as they arrive.

Visual Twin Viewer

Digital Twin Enhancements The Digital Twin component has been enhanced to include a number of new features, including:
- Digital Twin Legend & Iconography: Visually distinguish Sensors (blue dots), Calculated Fields (black plus-signs) and Alert Conditions (green/yellow triangles based on false/true values). In addition, Things/Assets are now represented as color-coded Standard Asset icons.
- Digital Twin Timeline: The history of points-in-time are available to review / compare values, with easy navigation using arrow-keys and support for both in-memory values and snapshots.
- Digital Twin Snapshots: Any Digital Twin point-in-time (full asset hierarchy) can be saved to Salesforce as an IoT Data Snapshot record. These snapshots are loaded in the viewer on the timeline for reviewing / comparison.
- Digital Twin Streaming: The ability to subscribe to the IoT stream of data for ALL Assets in the Digital Twin Hierarchy is also available, allowing the user to view the latest values as they arrive.

Digital Twin Enhancements

Simulator Enhancements Stream your Bolt Data Connect IoT Data into Salesforce Data Cloud. We automate the schema and integration to make the setup painless and make it easy to analyze and act on your IoT Devices in Data Cloud.
- Local Simulators: The same Simulator configurations run in the Salesforce browser, giving better stablity and control. (NOTE: This also allows Simulators to be used in BDC-Lite & Demo-Kit)
- Simulator Replay Files: Admins can now download Thing Chart data, representing an interesting use-case or problematic scenario, (optionally) modify the data, and upload to a Local Simulator to replay the same data. This enables them to test very specific scenarios and have complete control over simulated values.
- Simulator Co-Pilot: Save time and avoid missed sensors and modes by using the new Simulator Config Co-Pilot feature to auto-Generate Simulator Definitions using analytics and introspection of the rules.
- Simulator Config Permission: Ability to restrict the editing of the Simulator Configurations, separate than the use / control of the Simulators themselves

Simulator Enhancements

Sensor Data: Asset Attributes Asset Attributes is a new Standard Object used in Salesforce Field Service and Manufacturing Cloud in Usage-Based and Condition-Based PM Plans. We’ve added support for populating these objects automatically by synchronizing the values from the IoT Cloud as well as automating the creation of the Asset Attribute Definitions.

Sensor Data Asset Attributes

Thing Registration Certificates The Thing Registration action now returns the generated security certificates needed for connecting to the IoT Cloud. The Administrator can now download these certificates to handle the edge connectivity without leaving Salesforce.

Thing Registration Certificates

Smart Gateways We’ve added more intelligent monitoring of our Gateways, including:
- Gateway Alarms: Central monitoring of important runtime problems and warnings from Gateways and their connected Things.
- Gateway Metrics: The Telemetry data sent by the Gateways now includes key metrics for each Thing Type being processed.

Gateway Metrics

IoT Audit Trail: A new Audit Trail table in the IoT Cloud captures key events such as Register API, Gateway Integration Update API, and Thing Type Update API. The Audit table includes columns for Audit-Type, Datetime, Textual Difference (DIFF), and JSON Value. This enhancement ensures a comprehensive record of crucial actions.

NOTE: This IoT Audit Trail data is not currently exposed in Salesforce, but you can create a Case with support (bolt-data-connect-support@bolt-data.com) if you need access for any reason.

Docs: Release 3.3 (Summer '23)

Thu, 20 Jul 2023 00:00:00 +0000

New Features:

Gateway Management Console The Console tab on a Gateway allows you to send/receive messages (IoT Commands) to the Gateway. The catalog of out-of-the-box Command Templates now includes 11 commands.

Gateway Management Console - Command List

Thing Chart Enhancements The Thing Data & Snapshots component has been enhanced to include a number of new features, including:
- IoT Alerts: Shown as color-coded vertical annotations with the Alert Type labels
- Enhanced Legend: Separated from Chart widget to adapt to high volumes
- Split Axis: Splits the values across 3 Axes based on the maximum absolute values

Thing Chart Enhancements

Data Cloud Integration Stream your Bolt Data Connect IoT Data into Salesforce Data Cloud. We automate the schema and integration to make the setup painless and make it easy to analyze and act on your IoT Devices in Data Cloud.

Data Cloud Integration

Docs: Release 3.2 (Spring '23)

Fri, 05 May 2023 00:00:00 +0000

New Features:

Gateway Management Console The Console tab on a Gateway allows you to send/receive messages (IoT Commands) to the Gateway. The catalog of out-of-the-box Command Templates will expand in future releases.

Gateway Management Console

Manual Sensor Entry The Thing Details component allows you to manually submit Sensor Values for this specific Thing to the IoT Cloud.

Manual Sensor Entry

Servitization Testing Console On the Servitization Plan, the Console tab provides a Testing Console to ease the Servitization Plan testing effort, by automating the required steps and simplifying the process.

Servitization Test Console

Sensor Data Sync Advanced Options A sensor value can be used as the “Timestamp” of the synchronized Sensor Data. This Timestamp influences downstream processes like Servitization and Reporting. If these fields are NOT filled in, the system will use the default Timestamp in our IoT metadata which indicates the date/time when we received the IoT message.