Bolt Data Connect – IoT Setup

Docs: Global Settings

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

Docs: Thing Types

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

Thing Types allow you to configure “no-code” metadata to control the data model, frequency, and business logic of the IoT Cloud and Edge Gateway processing, all from within Salesforce.

Thing-Type Configuration

Organizing your Thing-Types is crucial for unlocking the full potential of the Bolt Data Connect App. Each Thing is assigned a Thing-Type and it’s this Thing-Type that determines what calculations are performed on your Thing’s data and what Alerts get propagated to Salesforce.

Each Thing-Type defines all interesting Sensors, Calculations and Alert Conditions for a Thing of that type. It also defines how data is aggregated in the IoT Cloud. The IoT Rules Engine performs all Aggregations, Calculations, and Alert Conditions at the Edge, reducing the load on the IoT Cloud infrastructure, and saving you money.

Digital Twin Roles allow you to define relationships between Thing Types. This gives you the ability to create calculations and alerts based off of related Thing values as well.
Sensors allow you to define how each field in your Thing’s data is aggregated, what data type to assume for it and whether or not to send or save that data to the cloud.
ML Inferences allow you to add the result of executing an ML Model with a set of input values from IoT Sensors.
Calculated Fields allow you to enrich a Thing’s data prior to entering the Cloud. Calculations can use any Sensors or other Calculations within the scope of a Thing. For example, Calculations can allow you to derive a state based on Sensor data, then use that state to drive an Alert.
Alert Conditions allow Things to communicate with Salesforce. They are the catalysts that drive your Processes and State changes in Salesforce. You have full control over what constitutes an Alert and how often to rebroadcast that Alert when the state hasn’t changed after a specified time. Alerts can use any Sensors or Calculations within the scope of a Thing.

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

Bolt Data Connect – IoT Setup

Docs: Global Settings

Docs: Thing Types

Thing-Type Configuration

Docs: Visual Twins

Visual Twin Setup

Note

Docs: Digital Twins

Digital Twin Field Bindings

Digital Twin Children (in Thing Types)

Note

Digital Twin Types

Note

Digital Twin Diagram / Editor

Digital Twin API

Docs: Context Data

Global Context Fields

Name Restrictions

Thing-Type Context Fields

Context Synchronization

FYI

Remove Context Field

Docs: Sensor Data

Field Definitions

Asset Attributes

Note

Advanced Sensor Bindings

Sensor Synchronization

FYI

Docs: Auto Registration

Registration Settings

Registration Expressions

Registration Job

FYI

IoT Registration Object

NOTE

Docs: Geo-Coding

Address Definitions

NOTE

Address Formats

NOTE

Geo-Coding Job

FYI

Docs: Data Snapshots

Add Parent Object

Note

Remove Parent Object

Docs: Alert History

Field Definitions

Alert History Cleanup

FYI

Docs: Servitization Setup

Note

Field Definitions

Servitization Mappings

Note

Note

Hint

Note

Servitization Job Scheduling

Recommendation

FYI

Docs: Thing Downtime

Field Definitions

Sample Downtime

Docs: Data Lake Calculations Setup

Data Lake Calculation Editor

Metrics Frequency(s)

Metrics Fields

Note

Data Lake Calculations Synchronization

COUNT Metrics

Data Lake Calculations Job Scheduling

Recommendation

FYI

Data Lake Calculations Dashboard & Reports

Docs: Machine Learning

Machine Learning Model Process

Data Pipeline (Data Engineering)

Model Pipeline (Data Science)