Bolt Data Connect – Salesforce

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

Fri, 28 Jul 2023 00:00:00 +0000

Represents an IoT Gateway, the entry-point for IoT messages and a container for Connectors and Rules-Engine processing.

Sample Gateway

Gateway Auto-Registration

As Gateways are registered with the IoT Cloud, an IoT Gateway Alert will be sent and the Gateway will automatically be created. The following fields will be filled in automatically:

Name: The Gateway Name will be auto-filled with the Gateway Id, but it can be overriden.
Gateway Id: The Unique Gateway Id. This value should not be edited.
Gateway Type: The ThingType of the Gateway. This value should not be edited outside of the Registration Quick Action.
Gateway Status: As IoT Gateway Alerts are received, the Gateway Status is automatically updated to match the latest value.

Gateway Manual-Registration

Gateways can also be created in Salesforce, and then registered with the IoT Cloud using the Registration Quick Action. The Gateway Id and Gateway Type will need to be specified, and the IoT components will be auto created and be ready for downloading & setup of the Edge Gateway.

Gateways on the IoT Console

The IoT Console is the centralized dashboard for viewing all IoT Things within an Org. Gateways will be displayed on the Map for all Things matching the current filter, if they have the Geo-Location fields filled in.

The Map now has Clustering in addition to Overlays, allow the user to filter Things, Gateways or both.

Gateway Maps

Gateway Chart and Digital Twin

The IoT Gateway can also display the Thing Chart and Digital Twin components.

Like any other Thing, the IoT Gateway sends Telemetry (time-series) data at a regular interval and can be configured with Calculated Fields and Alert Conditions in it’s corresponding Thing Type. The Sensors are mostly focused on the performance of the device hosting the Gateway & Rules-Engine.

Alarms and Metrics

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

Gateway Integrations Editor

The Gateway Integrations editor provides easy interface for controlling the flow and transformation of messages from Things registered to the Gateway. As IoT messages are received into the Gateway, it will lookup an Integration below to determine the appropriate Connector => Transformer => Stream, or “Integrtion Path”.

Connectors

Connectors are components that can be deployed to a Gateway to integrate to custom API, data-store, or other source for ingestion of IoT messages / data. By default, every IoT Gateway will include an mqtts connector but others can be deployed by contacting support.

Integration Editor: Connectors

NOTE

You can Add Connectors, and configure the parameters of existing Connectors through this editor but they will not be deployed to the Gateway until you’ve contacted support (see above).

Integration Groups

Groups allow you to define the “Integration Path” for all Things of a certain ThingType at once. Start by selecting the ThingType, or select “*” to setup the Default, and then the desired Connector, Transfomer and Stream.

Integration Editor: Groups

NOTE

You’ll notice that by default a Default Integration Group is configured. For any standard MQTT Connector setup this does not need to be edited.

Thing Integrations

Thing Integrations allow you to override a portion, or all, of the Integration Path for each registered Thing. For example, you may choose to select a specific Transformer for a Thing that needs debugging. Or you may need to specify unique parameters to the Connector for each Thing as seen below.

Integration Editor: Things

BEST PRACTICE

As Things are Registered to the Gateway they will automatically show up in this list, and do not need to be added manually.

Gateway Management Console

The Console tab on a Gateway allows you to send/receive messages (IoT Commands) to the Gateway. The following catalog of out-of-the-box Command Templates is currently available:

Clear Registration Cache
Get Connector Status
Get Device Cache (Thing)
Get I/O Status
Get Registration Cache (All)
Get Registration Cache (Thing)
Get ThingType Cache
Restart Virtual Gateway
Test Thing Data
Reset ThingType Cache: Forces the Gateway Rules Engine to reload the ThingType
Reset Registration Cache: Forces the Gateway Rules Engine to reload the Gateway’s & Thing’s Registration and Integrations

Gateway Management Console

Custom Commands

Select the CUSTOM command to use a freeform editor to send any custom command message to the Gateway.

Restart Gateway

Description: It restarts a gateway. It does not apply to an asset.
Type: Request-Reply

Topic:

// topic pattern:
iot/gateway/+/command/+
iot/gateway/{gateway_id}/command/{command_name}

// example
iot/gateways/VirtualGateway-PLAATO-USEAST1-DEV-01/command/restart

Body

// example
{
  "request_id": "ppate1690571776080"
}

Get Registeration Cache (All)

Description: It retrieves registeration caches of all assets and gateways
Type: Request-Reply

Topic:

// topic pattern:
iot/gateway/+/command/+
iot/gateway/{gateway_id}/command/{command_name}


//  example
iot/gateways/VirtualGateway-PLAATO-USEAST1-DEV-01/command/get-thing-cache

Body

{
  "request_id": "ppate1690571863558"
}

Get Registeration Cache (Thing)

Description: It retrieves registeration cache of a specific thing. A thing could be gateway or asset.
Type: Request-Reply

Topic:

// topic pattern:
iot/gateway/+/command/+
iot/gateway/{gateway_id}/command/{command_name}


//  example
iot/gateways/VirtualGateway-PLAATO-USEAST1-DEV-01/command/get-cache-thingid

Body

{
  "thing_id": "{thing_id}", // e.g., 10P-KEG01, VirtualGateway-PLAATO-USEAST1-DEV-01
  "request_id": "ppate1690572125580"
}

Clear Registeration Cache

Description: It clears registeration cache of a thing. A thing could be gateway or asset.
Type: Request-Reply

Topic:

// topic pattern:
iot/gateway/+/command/+
iot/gateway/{gateway_id}/command/{command_name}


//  example
iot/gateways/VirtualGateway-PLAATO-USEAST1-DEV-01/command/clear-cache

Body

{
  "thing_id": "{thing_id}", //e.g., VirtualGateway-PLAATO-USEAST1-DEV-01, 10P-KEG01
  "request_id": "ppate1690572498198"
}

Get ThingType Cache

Description: It retrieves specification cache of a thing type.
Type: Request-Reply

Topic:

  // topic pattern:
  iot/gateway/+/command/+
  iot/gateway/{gateway_id}/command/{command_name}

  //  example
  iot/gateways/VirtualGateway-PLAATO-USEAST1-DEV-01/command/get-spec-cache

Body

{
  "thing_type": "{thing_type}", //e.g., Brewing_Keg, Virtual_Gateway_PLAATO
  "request_id": "ppate1690572761850"
}

Get IO Status

Description: It retrieves status of various IOs.
Type: Request-Reply

Topic:

  // topic pattern:
  iot/gateway/+/command/+
  iot/gateway/{gateway_id}/command/{command_name}


  //  example
  iot/gateways/VirtualGateway-PLAATO-USEAST1-DEV-01/command/get-io-status

Body

// example
{
  "request_id": "ppate1690573052355"
}

Get Connector Status

Description: It retrieves status of all connectors attached to a gateway.
Type: Request-Reply
Topic:

  // topic pattern:
  iot/gateway/+/command/+
  iot/gateway/{gateway_id}/command/{command_name}

  //  example
  iot/gateways/VirtualGateway-PLAATO-USEAST1-DEV-01/command/get-connector-status

Body

//example
{
  "request_id": "ppate1690573316704"
}

Get Device Cache

Description: It retrieves cache of a device data
Type : Request-Reply
Topic:

  // topic pattern:
  iot/gateway/+/command/+
  iot/gateway/{gateway_id}/command/{command_name}

  //  example
  iot/gateways/VirtualGateway-PLAATO-USEAST1-DEV-01/command/get-device-cache

Body

// example
  {
    "thing_id": {thing_id},
    "request_id": "ppate1690580697957"
  }

Test thing data

Description: It lets your test your data. It inputs sample data of an asset/gateway and outputs processed data from rules-engine.
Type: Request-Reply
Topic:

// topic pattern:
iot/gateway/+/status/+
iot/gateway/{asset_id}/status/{request_id}

//  example
iot/gateways/VirtualGateway-PLAATO-USEAST1-DEV-01/command/test-thing-data

Body

// example
{
  "externalKey": "{asset_id}", // e.g., 10P-KEG01
  "request_id": "ppate1690573756372",
  ... // add sensor data
}

Reset Registration Cache

Description: It resets cache of an asset or an gateway.
Type: Broadcast
Topic:

// topic pattern
iot/cache/registration/{asset_id}/invalidate


// example
iot/cache/registration/10P-KEG01/invalidate

Body

// example
{
  "externalKey": "{asset_id}", //e.g., 10P-KEG01
  "message": "Manual Registry cache reset."
}

Reset ThingType Cache

Description: It resets cache of thingtype. A thingType could be a gateway or thing
Type: Broadcast
Topic:

// topic pattern
iot/cache/specification/{thing_type}/invalidate


// example
iot/cache/specification/Brewing_Keg/invalidate

Body

// example
{
  "thingType": "{thing_type}", //e.g., Brewing_Keg
  "message": "Manual Registry cache reset."
}

MQTT Template

Type: The type of message (Broadcast, Request-Reply). NOTE: In the initial release only Broadcast is supported.
Topic: The MQTT Topic to publish the command to
Body: The JSON payload of the command

NOTE

This is especially useful if you are using a custom connector. This will allow you to publish a message to the Gateway, which will in-turn publish it to the connector itself. Use the following topic format for Connector commands: iot/gateways/{GATEWAY_ID}/connector/xxx

Docs: Things

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

All of the below components are implemented as Salesforce Lightning Web Components. They can be included on the thing object’s Lightning Record Page, and can be shown / hidden from users using the filters available.

Thing Details

The Thing Details component shows the current status of a connected Thing. It shows:

External Key: The unique Id assigned to this thing / device.
Gateway: The Gateway this Thing is connected to.
Thing Status: The current IoT Status reported by this thing.
Thing Type: The ThingType (from IoT Setup) that this thing will use. This value should not be edited outside of the Register Action.
Context: The latest status on the synchronization of Salesforce “Context Data” that has been sent to the IoT Cloud for this thing.

Thing Details

Thing Registration (Thing Details)

The Thing Details component allows you to Register a new thing by selecting the following:

External ID: The unique Id assigned to this thing / device.
Gateway Assignment: The Gateway this Thing will be connected to.
IoT Type: The ThingType (from IoT Setup) that this thing will use. This value should not be edited outside of the Register Action.

Thing Registration Certificates

The Thing Registration action 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.

Push Context Data (Thing Details)

The Thing Details component allows you to manually push the Context Data for this specific Thing to the IoT Cloud.

This could be useful if the Context Values have changed for this Thing, and you don’t want to wait for the next scheduled Context Sync job to run.

After clicking the button, wait about 30-60 seconds and refresh the page to verify the updated Context Sync status.

Sync Sensors (Thing Details)

The Thing Details component allows you to manually pull the latest Sensor Data for this specific Thing from the IoT Cloud.

This could be useful if the Sensor Data have changed for this Thing, and you don’t want to wait for the next scheduled Sensor Sync job to run.

After clicking the button, wait about 30-60 seconds and refresh the page to verify the updated Sensor Data records.

Thing Details

Manual Sensor Entry (Thing Details)

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

Manual Sensor Entry Button

This could be useful if this Thing is not able to communicate due to security/firewalls or is temporarily disabled. The manually entered sensor values are uploaded and processed by the Rules Engine and stored in the IoT Cloud Data-Lake just like they would if they were received as a real IoT message.

Manual Sensor Entry

Note

It’s important to add to this Manual Sensor Entry form is dynamic, based on the Sensors defined in the Thing Type. The Data Type and Storage Data Type influence the type / validation of each field on the form.

Deregister (Thing Details)

The Thing Details component allows you to De-Register a thing. This will remove the thing from the registry and stop the flow of data and reduce device licensing.

Thing Data & Snapshots

By default, the 25 most recent messages will be displayed in the chart tab. This chart is fully interactive: zoom in/out, select/deselect sensors to hide/show them, scroll left/right, etc.

Thing Data Chart

The data tab allows you to see the same messages displayed in the chart tab, but in tabular/spreadsheet format, and download as a CSV file.

Thing Data Table

The snapshots tab allows you to view saved Snapshots and apply custom filters. Instead of the most recent 25 messages, the user can apply a dynamic filter for more messages and/or for a specific date/time range. Once a filter has been applied, you can also save the filtered data into a “Snapshot” in Salesforce attached to this thing record.

Thing Data Filter

Live Stream

The Thing Chart now has the ability to Live Stream IoT data. After clicking on the “Play” Stream button, you’ll see the chart re-draw with each new message as it is received from the IoT Gateway.

Thing Chart Live Stream

Note

It is possible to stream data for a period of time, and then save it to a Data Snapshot. Simply click the Save icon.

Alerts

By clicking the Alerts button the Alert History for the current Thing will be overlaid on the Chart as vertical annotations, color coded with text descriptions of the Alert Type received.

Thing Data Chart: Alerts

Legend

The Thing Chart Legend can be configured in the Lightning Record Page setup as:

Salesforce: The legend will be rendered as Lightning Web Component “widgets”, separate from the Graph itself. (Default)
Built-In: The legend will be rendered as part of the Chart widget itself.

Note

The Salesforce view is more robust, adapts to Split axes, and does not affect the rendering of the Chart itself. However, the Built-In view is useful when capturing an Image of the Chart as an Attachment, so the legend is included.

Split Axes

The Thing Chart can now split the plotted values across 3 Axes by separating them by their maximum absolute values.

Thing Data Chart: Split

Note

By default these splits are defined as 0-10, 10-100 and 100+ but these ranges can be customized in the Lightning Record Page editor.

Thing Commands

This component allows the user to send a Command to a thing. Bolt Data Connect will route your command to the IoT Cloud, then the Edge Gateway, and ultimately to the device itself. Keep in mind that the device must know how to interpret this command for it to respond accordingly.

Thing Command

Digital Twins

See the 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 Viewer

The Legend shows the notation of the diagram including Sensors, Calculated Fields and Alert Conditions
Use the Digital Twin Toolbar to:
- Refresh the latest values
- Stream to subscribe to IoT Cloud messages as they are received
- Clear to reset and clear history values not already saved as IoT Snapshots
- Save to create an IoT Snapshot from the currently selected Digital Twin point-in-time
Select a different point-in-time to view the Digital Twin values from that time

Visual Twins

See the Visual Twin Editor for configuring the Visual Twins in IoT Setup.

On the Thing Record Page, add the IoT Visual Twin and easily view the configured Visual Twin from any Thing. The component shows the uploaded Image, as well as real-time IoT data in to the configured Annotations. Simply hover over any annotation area to see the IoT Values.

Visual Twin Viewer

Hover over an Annotation to view the IoT Field values
Use the Visual Twin Toolbar to:
- Refresh the latest values
- Stream to subscribe to IoT Cloud messages as they are received
- Clear to reset and clear history values not already saved as IoT Snapshots
- Save to create an IoT Snapshot from the currently selected Visual Twin point-in-time
Select a different point-in-time to view the IoT Field values from that time

Thing Timeline

On the Thing Record Page, add the IoT Thing Timeline and easily view the configured Timeline events for any Thing. The component shows the events of each configured type related to the Thing.

Included in the initial release, the following IoT Timeline Configuration (Custom Metadata) have been included:

IoT Registrations
IoT Alert History
Asset Downtime Periods
Servitization Coverage
Cases
Work Orders

Thing Timeline

Note

Any other Timeline object/event can be configured in:

Setup > Custom Metadata Types > IoT Timeline Configurations.

IoT Timeline Configuration

IoT Copilot

Add the IoT Copilot to the Asset Lightning Record page to give your users the ability to ask natural language questions in a chat window. They can ask questions about an asset’s performance based on IoT telemetry data and alert history, unlocking instant insights.

IoT Copilot

Note

Salesforce AgentForce licensing is not needed to take advantage of the IoT Copilot. We are using Generative AI models behind our IoT Cloud API layer, utilizing a world-class Trust Layer to protect the data and privacy.

If you are using Agentforce, the IoT Copilot 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. Please reach out to our support team for more information.

When adding the IoT Copilot to a Lightning Record Page, you can configure the following options:

Default Model:
Bot Name (IoT Copilot is the default)

On the IoT Copilot component, you can also click the setup icon to try a different model:

IoT Copilot Models

Advanced

The Generative AI Prompts can be also be customized by modifying these Custom Labels:

IoT Copilot Prompts

Sensor Gauges

The “IoT Sensor Gauge” Lightning Web Component (LWC) can be added to a Screen Flow to render sensor values as Gauges or Progress Bars/Rings. In addition, we’ve provided a Custom Action and Screen Flow template to ease the setup.

Create a New Screen Flow, using the IoT Gauges Template

IoT Gauges Flow Template
In the Flow editor, feel free to add/remove/edit the IoT Sensor Gauge components as you’d like. Make sure to fill in the “IoT Values (JSON)” with the value returned from the provided Action.

Sensor Gauges Flow Editor
Add the Screen Flow to the Lightning Record Page to view Sensor Gauges:

Sensor Gauges

Docs: Alert Response

Wed, 15 Jun 2022 00:00:00 +0000

In the Thing Types you define the Digital Twins, Sensors, Calculated Fields and Alert Conditions for every type of “Thing” you need to connect. When those Alert Conditions fire the IoT Cloud sends an IoT Alert to Salesforce. Alert Response handling is a clicks-not-code solution to handling these IoT Alerts.

You can auto-create any response Object (Case, Work Order, Lead, etc.) in response to an IoT Alert, and customize how different Thing Types and/or Alert Types are handled. In addition, you can configure Thing (Asset) updates, auto-created related child records, auto-create IoT Data Snapshots and exit condition updates (e.g. Cancel Work Order, Close Case, etc).

Alert Response Setup

Each Alert Response definition can be broken into two sections:

Conditions - What conditions cause this Alert Response to be executed?
Actions - What actions need to be taken when entering / exiting this response?

When an IoT Alert is received, the system will find the first Alert Response with matching “Conditions” (sorted ascending by Priority) and execute it. It will also first execute the “Exit” condition of the previous Alert Response, if applicable.

Alert Response Conditions

Priority: Numeric sort order for Alert Responses, the first one which evaluates to true is selected
Thing Types: Which Thing Types are included in this Alert Response? Select * for all.
Alert Types: Which Alert Types are included in this Alert Response? Select * for all.

NOTE: This is different than the Alert Condition Name. Alert Type values can be reused if desired.

Alert Response Conditions

Alert Response Actions

NOTE: Before assigning the below mappings to an Alert Response, you have to create them using the Object Mappings tab first.

Alert Response Actions

Thing Update Mapping: Update the Thing record with data from the IoT Alert (e.g. Thing Status, Sensor Values, etc.) Use the “New Thing Update” button on the Object Mappings tab
Alert Response Mapping: Create a new record in response to the IoT Alert (e.g. Case, Work Order, Opportunity, etc.) Use the “New Response” button on the Object Mappings tab
Alert Response Exit Mapping: Update the previously created response record, when a different Alert Response is executed in response to the IoT Alert (e.g. Case, Work Order, Opportunity, etc.) Use the “New Response Exit” button on the Object Mappings tab

NOTE: The Target Object of the Alert Response Mapping and Alert Response Exit Mapping MUST match.

Data Snapshot (minutes): Specify a start & end offset in minutes to create an IoT Data Snapshot attached to the response record.

NOTE: It’s typical to use a negative value in the start, indicating X minutes BEFORE the IoT Alert. If the end value is less than or equal to zero the Data Snapshot will be populated immediately. If it is positive, indicating X minutes AFTER the IoT Alert, the data will be populated using a scheduled background job after that time limit.

Send Response Alert: Should a separate “IoT Response Alert” be sent after processing the initial IoT Alert? This secondary alert will include all of the original values, plus the result values from the Alert Response. This is typically only needed if further automation will be triggered which needs the IoT data as well. See IoT Response Alert below.

Object Mappings

Alert Response Object Mappings

New Thing Update: Creates a new Object Mapping with Source Object of “IoT Alert” and Target Object of the configured “Thing” (e.g. Asset). This mapping will update the Thing record when executed.
New Response: Creates a new Object Mapping with Source Objects of “IoT Alert” & configured “Thing” Object (e.g. Asset) and Target Object of any Standard or Custom SObject available in the system. This mapping will create a new record when executed.
New Response Exit: Creates a new Object Mapping with Source Objects of “IoT Alert” & configured “Thing” Object (e.g. Asset) and Target Object of any Standard or Custom SObject available in the system. This mapping will update an existing record when executed, so it’s important that the Target Object should match the corresponding Alert Response Mapping.
New Response Child: Creates a new Object Mapping to create Child records (e.g. WOLI, Case Line, etc.) related to a Response Mapping. This mapping will have Source Objects of the “IoT Alert” & configured “Thing” Object, plus a Parent Object (e.g. Work Order, Case, etc) and a joined Child Object. (See the Alert Response Children section below)

Object Mappings

Source Object(s): All of the available Objects to map data from. All fields of these Objects will be available in the “Source / Value” columns with the “Mapping Type” of “Field”. These Source Objects are determined by the “Mapping Type” (see above)
Target Object: The Standard or Custom SObject to create/update with this Object Mapping

Field Mappings

Show All / Hide Unmapped: Toggle button to show / hide unmapped fields of the Target Object

Mapping Type

None This field will not be mapped
Field The source field will be copied into the target field
IoT Field Select the IoT Data field (typically the “Thing Data” field) and specify a Sensor or Calculated Field name to copy into the target field
Value The input value will be copied into the target field
Formula Simple formula syntax allowing for concatenation of Fields and Text Values into the target field

Alert Response Children

In addition, you can also auto-create related child records (Work Order Lines, Service Appointments, Case Lines, etc) by joining data from the IoT Alert & “Thing” to related data using a Filter Expression, then applying a Response Child Mapping to create the child records.

Alert Response Children Flow

For each Alert Response Child configured, the Filter Expression is applied first, finding 0 or more records. These records are then fed into the Child Mapping along with the previously created Response Object, creating new child records as seen above.

Alert Response Children

Filter Expression: Use data from the IoT Alert and “Thing” to filter records to “join” to. For example, you can find “Recommended Parts” records based on the Product & Problem Code combination as seen below.

Expression (Filter Children)

Child Mapping: Map values from the IoT Alert & “Thing”, as well as the “Parent Object” (e.g. Work Order, Case) and the “Child Object” which was filtered above, into the Target Object.

Object Mapping (Response Children)

NOTE: Make sure to map the “Parent Object” Id into the Target Object so that they are related

IoT Response Alert

When an Alert Response is executed, it can optionally send a new Platform Event with all of the original IoT Alert values, PLUS values indicating what Alert Response was executed as well as the resulting values and status of that Alert Response.

The resulting Platform Event will be of the type SPKI__IoT_Response_Alert__e and you can configure a Platform-Event Triggered Flow or Apex Trigger from this event.

IoT Response Alert (Fields)

Docs: Servitization

Sat, 15 Jan 2022 00:00:00 +0000

Servitization is the ability to use IoT data to drive “outcome as a service” for your customers. By setting up a Servitization Plan, with both Usage and Uptime based items, you can automatically generate invoices / quotes for customers based on their use of your IoT connected assets.

Servitization Setup

Visit the Servitization Setup help document to understand the settings which control how the Servitization job will generate Servitization Details and also control which output Objects will be created from the details.

Servitization Templates

Templates are a special kind of Servitization Plan created to specify a reusable configuration of Servitization settings and Items.

New Servitization Template

Note

See below for details on specifying Servitization Items. They are the same for Plans or Templates.

Once a Servitization Template Plan is created, use the Create Plan action to create a copy of the plan / items for a specific Account, Dates & Covered Things.

Servitization Plans

Servitization Plans specify the items & coverage for tracking the IoT driven “outcome as a service” for your customers. In other words, it defines the items you are intending to charge your customer for, as well as which of your connected assets are covered or included. Each Servitization Plan is specific to an Account & Pricebook, and in addition to the items & coverage it also specifies the frequency & granularity of the output details. This output typically correlates to an “Invoice” that will ultimately be sent to your customer on a regular interval. This output is dynamically mapped to any Salesforce Objects in the IoT Setup screens.

Servitization Plan

Price Book: Select the Pricebook that has includes the Servitization Products.

NOTE: These Products are not the same as the Asset’s product. They will be “usage” or “time” based.

Default Business Hours: Important for Uptime items, this lookup specifies the default Business Hours to use for calculating billable time.
Output Frequency / Type: These fields work together to specify how often an output object will be generated by the Servitization job.
Output Line Granularity: Affects how many output lines will be created, to control the granularity of detail provided to your customers in the output.

Product: Each Item / Product is a single line, with all details + things combined
Thing: Each Item / Product + Thing is a single line, with all details combined
Detail: Each Item / Product + Thing + Detail is a single line

Negative Usage Policy: For Usage Based Items, if a negative change in value is detected this controls which of the following actions the system will automatically take:

Require Approval: The Detail will be flagged as “Needs Approval” and a User will need to approve or change Quantity to a positive value.
Require Positive Value: The Detail will be flagged as “Needs Approval” and a User will need to change Quantity to a positive value.
Allow Negative Value: Negative Values will be allowed.
Error: The Detail will not be processed, and an Error will be logged (either to Chatter or IoT Admin Logs). The Sensor Data should be corrected before re-running the job.

Servitization Plan

Embedded Pricing

Servitization Plans can be configured with all of the pricing embedded, without the need for a Pricebook.

Price Book: Leave the Price Book blank on the Servitization Plan
Item Base Price: Fill in the Base Price on each Servitization Item
Tiered Price Book Entries: (OPTIONAL) Add Tiered Price Book Entries to the Servitization Plan related list

Tiered Pricing

These Embbeded Tiered Pricing records can also be specific to Coverage (Thing/Asset) by filling in the Coverage lookup field. This allows the Administrator to set prices specific to individual Coverage which override the default pricing.

Tiered Pricing with Coverage

Servitization Items

We currently support both Usage and Uptime based items. The following fields are common on both types of items:

Servitization Product: The product that defines the “outcome as a service” you are charging to your customers. This product must have a Price in the Price Book linked to the Servitization Plan.
Base Price: This field will be auto-populated from the Servitization Product / Price Book Entry if a Pricebook is assigned to the Plan. If no Pricebook is assigned, this field must be manually populated.
Qty Calculation: Used in conjuntion with the Per Qty field to calculate the Qty for Servitization Details.

EXACT: No rounding. The Qty will be the exact fraction as calculated by the actual measurement and Per Qty values.
ROUND-UP: Round the value up to the nearest whole Per Qty value.
ROUND-DOWN: Round the value down to the nearest whole Per Qty value.

Per Qty: The Quantity that each priced Servitization Product represents. (e.g. Uptime might be sold in 4 hour blocks, Usage might be sold in 100 count chunks)
IoT Thing Type: Which Thing Type does this Servitization Item apply to?

NOTE: Use the Editor on the Servitization Item page to set this value after creation.

Servitization Frequency / Type: How often will Servitization Details be created for each Item for each Covered Thing.

Advanced Pricing

Skip $0 Output: Skips the Output line if the calculated line price is $0
Pricing Policy: Used to determine the calculated price for each Servitization Detail / Output line.

Base Price: Simply uses the “Base Price” field on the Servitization Item
Base Price with Overage: Uses the Item “Base Price” with a single Tiered Price Entry for Overage with a Min Qty (and blank Max Qty) and Price
Average Tier Pricing: Priced by Tier based on Averages of Total per Servitization Item
Per Tier Pricing: Individually Priced Lines for each Tiered Price (outputs lines for each Tier)
Single Tier Pricing: Single Output Line for Total Qty Tier Price
Total Tier Pricing: Priced by Tier based on Total per Servitization Item

Reconciliation Count: Number of Outputs to Reconcile together, before calculating a Tiered Price. (Default is 1)
Skip Delta Calculation: When checked, indicates that the IoT Value will be a delta (difference since last reading) and that the system should not calculate the difference but instead use this value in the Usage details.

Advanced Pricing

Uptime Items

Uptime items measure the time in which the IoT device was in good working order for the customer. We measure this by the amount of time the device was in “Normal” IoT Status (not “Offline” or “Alert”).

BUSINESS-HOURS

The default Business Hours on the Servitization Plan, or the specific Business Hours on the “Thing”, influence this greatly. Every Business Hours record is specific to a timezone so it is important to ensure this aligns to the device. In addition, if it is only 8 or 10 hours a day, that is the maximum billable hours in a day (as opposed to a 24 hour period). Keep this in mind and consider creating IoT specific Business Hours, instead of reusing your Field Service “Working Hours” possibly.

New Servitization Item: Uptime

In addition the fields above, Uptime Items must specify:

Uptime UOM: The Unit of Measure (UOM) to measure the Uptime.

Seconds
Minutes
Hours
Days

Edit Servitization Item: Uptime

Use the Servitization Item Editor to set the IoT Thing Type easily.

Usage Items

Usage items track & measure the value of a sensor on a specific kind of IoT device. These are typically a “counter” of some sort that tracks how many uses the customer has consumed.

New Servitization Item: Usage

In addition the fields above, Uptime Items must specify:

IoT Sensor Name: The name of the configured sensor (from the Thing Type specification) to track/measure

NOTE: Use the Editor on the Servitization Item page to set this value after creation.

Edit Servitization Item: Usage

IoT Tier Sensor Name: (OPTIONAL) The name of the configured sensor (from the Thing Type specification) to determine which Tiered Pricing band to use. This is useful when a calculation or combination of fields determines the “tier”, but the individual values need to be billed at the tiered price.

NOTE: Use the Editor on the Servitization Item page to set this value after creation.

Use the Servitization Item Editor to set the IoT Thing Type, IoT Sensor Name and IoT Tier Sensor Name easily.

Servitization Coverage

The coverage records denote which connected “Things” will be included in this Servitization Plan.

Servitization Coverage

Note

It’s important to add to this Coverage list as new IoT Things are Registered to ensure they’re included. Some customers have decided to automate this. In addition, the “Is Active” flag can be used to add Assets before activating them, and automating the activation on a specific date or event.

Servitization Details

The details records are auto-created by the scheduled Servitization Job. Each Servitization Item denotes the frequency and calculations used in creating these records.

Servitization Details

Servitization “Execute” / Output

The Servitization Setup screens specify what Output objects will be created. In addition, the Servitization Plan specifies the frequency that Output Objects are generated.

REMEMBER: This output typically correlates to an “Invoice” that will ultimately be sent to your customer on a regular interval.

Note

It’s recommended to add a Related List to the Servitization Plan of the Output Objects (e.g. Orders, Quotes, Proforma Invoices, etc.) for visibility and clarity.

Docs: Simulators

Sat, 15 Jan 2022 00:00:00 +0000

This section provides details on how to use and configure the IoT Simulator Console.

Simulators are runtime engines for testing IoT Gateways and Things. When you open the IoT Simulator Console, it connects to the IoT Cloud and detects all of the Simulators corresponding to this Salesforce org. These Simulators can “impersonate” devices by generating the messages typically sent from the actual devices.

Simulator Console

Note

The Simulator Console is available as a “Utility” item anywhere inside the Bolt Data Connect App in Salesforce. The utility items appear at the bottom left corner of the browser. It can be minimized/restored or you can use the “pop-out” feature.

Local Simulators

As of the Winter ‘24 Release, we’ve added a new “Local” Simulator. This new kind of Simulator runs in the browser and comes with a few new features, as well as a few differences in behavior.

They support all the same Simulator Configurations, Start/Stop/Reset functions and Edit Mode capabilities
Local simulators cannot host Gateways. Things added to this Simulator still need to be registered to a Gateway, but that Gateway cannot run in this Local Simulator. It should be either a Virtual or IoT Cloud Simulated Gateway
Because Local Simulators do not run in the IoT Cloud, they can be used in BDC-Lite and the BDC Demo-Kit (without an IoT Cloud)
When the browser window is closed (or refreshed), the Simulator stops sending messages. If you need a Simulator to run in the background for long periods of time we recommend using the IoT Cloud Simulators
Only Local Simulators support the new Replay File mode

Local Simulator

Controlling Simulators

There are different types of devices that show in the grid below:

Simulators (#1): Runtime Engine for simulated devices
Gateways (#2): Simulated IoT Gateways, complete with Rules Engine and all other features
Things (#3): Simulated IoT Things, connected to a Gateway

You can use the command actions (#4) to control the status (#5) of the simulated devices. First select the checkbox on the left of the devices, then click the following buttons:

Start: Changes the device to “running” status. It will begin to send messages.
Stop: Changes the device to “idle” status. It will stop sending messages.
Reset: Changes the device to “startup” status, and resets the in-memory values back to defaults. It will not send messages.
Add: You must first select a simulator you which to add a new simualted device to. Then, enter the “External Key” of either a Thing or Gateway into the Add dialog.
Remove: Removes the selected simulated device. (Does NOT remove it from Salesforce, only from the Simulator)

Modes (#6) are configured below, and define the different combinations of values being sent from the simulated devices. You can see which Mode every device is in, as well as change the mode using the edit button. This will cause the device to send different values, possibly resulting in an Alert Condition, to aid in testing and validation of the configured automation.

Simulator Console Controls

Note

If your simulated Thing shows “running”, but is not connected or sending data, it is possible there is a problem with the Simulator Config (next section). Double check all parameter values and types (Numbers, etc). It’s also possible that the Gateway might need to be re-registered.

Replay Files

An alternative to using the Simulator Config and Modes is to instead upload a “Replay File” of time-series data for the Simulator to echo back.

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 Replay Files

Select the Simulated Thing to replay
Click the Replay Upload button
Drag-and-Drop the time-series CSV file

You will notice that the Simulator Mode will indicate which message it has processed as it moves through the messages.

Note

This feature is only supported in Local Simulators currently.

Configuring Simulators

In the Configure Types tab, you can select any active Thing Type, and edit or create Simulator configurations to control how Simulated Things of that type will behave.

Each Thing Type (#1) can be setup with multiple “modes” (#2). You should always start with the default “Normal” mode, then configure alternate modes.

BEST PRACTICE

It’s a best practice to configure a mode to correspond to each Alert Condition to enable easy testing.

Each mode can define what simulated value will be returned for each Sensor. Click the Add Parameter button (#3) to add a new sensor value simulation, or click the Edit icon (#4) to edit an existing one.

Simulator Console Config

The following types of Sensor Parameters are currently supported:

Constant Constants will send the same “Constant Value” consistently.

Simulator Console Parameter - Constant
Counter The Counter is a numeric value. It will default to the “Start” value, and will change by the “Step” amount at each “Interval”. When it reaches the “End”, it will start over again.

Simulator Console Parameter - Counter
Random-Uniform The Random / Uniform is a numeric value. It will be a random number between the “Lower” and “Upper” values, and will change at every “Interval”.

Simulator Console Parameter - Random
Random-Choice The Random / Choice can be numeric, boolean, text, etc. It will randomly choose between the provided “Choice Values”, and will change at every “Interval”.

Simulator Console Parameter - Choice
Datetime The Datetime can be numeric or text. It will be recalculated on every message, relative to the current date/time. The Offset can be either positive (future) or negative (past), or 0 for current date/time. The format can either be epoch (to return the epoch in milliseconds) or a valid Python datetime format (e.g. %Y-%m-%d_%H:%M:%S) to return any textual date or time format.

Simulator Console Parameter - Choice

SAVE

After adding or editing the modes, don’t forget to Save Mode and then Save & Sync.

Simulator Configuration Co-Pilot

In the Simulator Configuration Editor, use the Co-Pilot “Generate” button to automatically create/update Simulator Definitions using analytics and introspection of the rules, based on the Thing Type setup. Multiple simulator modes are generated, saving the admin time and ensuring all alert conditions are covered.

Simulator Configuration Co-Pilot

Note

The Generate is safe to use as it doesn’t save anything, only makes changes in memory. If you’re not happy with the results, either Cancel or Edit them before Saving.

Simulator Console Permissions

The Simulator Console is only available to Licensed Bolt Data Connect Users, and only if they have been given one or both of the following Custom Permissions:

IoT Simulators: This Permission gives the user the ability to view and control Simulators (the “Monitor and Control” tab)
IoT Simulators Configure: This Permission gives the user the ability to create or edit the Simulator Configurations (the “Configure Types” tab)

Docs: Data Cloud

Fri, 28 Jul 2023 00:00:00 +0000

This section provides details on how to use the Data Cloud Integration, which provides Salesforce Data Cloud Users with visibility into the Bolt Data Connect IoT Data Stream.

Initial Setup

Start by creating a Case with Bolt Data Connect Support, requesting the setup of the Data Cloud Integration: Create DataCloud Support Case

Our support team will work with you by either setting up the Data Cloud components or sending you easy to follow instructions.

Once the integration is setup, you’ll have the following Bolt Data Connect Data Cloud components, automatically created from your custom IoT Thing Types:

Ingestion API
Data Stream
Data Lake Object
Data Model

Data Explorer

Once you have imported the components above you can now utilize the power of Data Cloud on your IoT Data.

Create Calculated Insights: Compute metrics across dimensions from mapped objects and fields.
Create Streaming Insights: Compute streaming metrics across dimensions from your real-time data sources.
Create Data Actions: Publish Events or Webhooks when data or insights conditions occur
Data Explorer: View / Report on the IoT data and insights

Log Search

Docs: Cloud Logs & Alarms

Fri, 17 Feb 2023 00:00:00 +0000

This section provides details on how to use the IoT Cloud Logs & Alarms, which provides Salesforce Users with visibility into the IoT Cloud Logs to help in troubleshooting calculations, alerts & connectivity issues.

Log Search

The “All Logs” search option allows you to search the IoT Cloud Logs for the APIs, Rules-Engine, and Connectors all from Salesforce. Enter a datetime range, (optional) keyword, select which Log Groups you are interested in searching.

Log Search

SIZE LIMIT

The results are limited to 1000 messages. Simply refine or narrow down your search if necessary.

TIP

You can also download the search results as a text file, simply scroll to the bottom and click Download.

Alarm Search

The “Alarms” search option allows you to search the IoT Cloud Alarms, which are preconfigured alarms configured by our IoT Cloud Support Team. These Alarms indicate that a threshold has been exceeded or resolved for an error condition. Enter a datetime range, (optional) keyword, select which Log Groups (Alarms) you are interested in searching.

Alarm Search

NOTE

Emails or other automated communications can be configured for these Alarms by contacting support.

Docs: IoT Setup

Thu, 05 Jan 2017 00:00:00 +0000

Docs: User Setup

Fri, 17 Feb 2023 00:00:00 +0000

This section provides details on how to setup Salesforce Users for Bolt Data Connect, including:

Permission Sets
Custom Permissions
Installed Package Licenses

Permission Sets

Included with the app are two Permission Sets which can be used as-is if your org uses Assets:

IoT Admins: Full Admin access to all Bolt Data Connect features including the IoT Setup tab.
IoT Users: Access to Bolt Data Connect data, visualizations, and interactions.

Each Bolt Data Connect User should be assigned to one of the above Permission Sets (or a Clone).

Note

If your org does not use Assets, we recommend that you Clone the above Permission Sets and add corresponding permissions on the appropriate Object(s).

Custom Permissions

The following Custom Permissions are included with the app:

IoT Setup: Access to the IoT Setup tab
IoT Simulators: Access to the IoT Simulators component (by default in the Utility Bar)
IoT Observability: Access to the IoT Cloud Logs & Alarms component (by default in the Utility Bar)

BEST PRACTICE

By default, all of these Permissions are included in the IoT Admins Permission Set only. You can choose to separate and give these Permissions as approriate for your Org.

Installed Package Licenses

To Add/Remove Licenses from Users:

Go to Salesforce Setup
Search for “Installed Packages”
Click “Manage Licenses” next to Bolt Data Connect
Add/Remove Users

User Licenses

NOTE

See all of the Licensing for your Bolt Data Connect Orgs including both Salesforce & Devices using the IoT Setup Licensing

Docs: Translations

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

This section provides details on the out-of-the-box included Language Translations and how to override and configure translations.

Included Components:

The following Lightning Web Components have been refactored to utilize Custom Labels. These Custom Labels have included Translations for the languages listed below. In addition, you can override the included Translations or add your own for any other Languages.

Utility Components:
- iotAlertSubscriber
- simulatorConsole
IoT Console Components:
- iotThingFilter
- iotFilteredThings
- iotMap
Thing Components:
- iotThingDetails
- iotThingChart
- iotThingCommand
- iotDigitalTwin
- iotVisualTwin
- iotThingSensorEntryModal

These Custom Labels control the titles, tabs, buttons and other output labels in the Lightning Web Components (LWC) as seen in the below example:

Component Translations

Included Objects:

The following Objects have included Translations for the languages listed below, for their Fields, Picklist Values, Record Types and Custom Actions. In addition, you can override the included Translations or add your own for any other Languages.

IoT Alert History
IoT Data Snapshot
IoT Gateway
IoT Registration
IoT Sensor Data
IoT Servitization Coverage
IoT Servitization Detail
IoT Servitization Item
IoT Servitization Plan
IoT Tiered Pricebook Entry

Included Languages:

The following Languages have been included for all of the above Components and Objects in the Summer ‘24 Release.

Danish: da
Dutch: nl_NL
Finnish: fi
French: fr
German: de
Italian: it
Norwegian: no
Portuguese (Brazil): pt_BR
Spanish: es
Swedish: sv

Overriding or Adding Translations

Use standard Salesforce translations to either override the included Translations or add additional Languages as described below:

Custom Object Metadata

Use the Setup > Translation Workbench > Override section to override or add Language Translations for any of our provided Custom Objects.

Override Object Translations

Custom Labels

Use the Setup > Custom Labels section to override or add Language Translations for any of our included Custom Labels.

Override Label Translations

Docs: Release Notes

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