Automate Connected Field Service
After an IoT alert is generated in CFS, you need to identify what your next course of action should be. The IoT alert record itself contains several pieces of information including the type of alert, time, device ID, and alert data. The Alert Data field consists of JSON data that contains specific details about the event. The data included can vary depending on the device. The information in the Alert Data field generally dictates what specific next step should be taken. When starting to build automations around next steps, it's important to understand what tools and information are available, and how those tools allow you to achieve your goal.
One way to simplify dealing with Alerts is by defining how they're grouped together as alerts are triggered. By default, similar alerts are grouped based on the Device that triggered the alert. However, there may be times when it makes sense to add an extra grouping layer. For example, an organization may elect to group alerts by related data such as Device Category, Account, or Customer Asset.
These settings are available from Settings - IoT Settings - Alert Aggregation Rules. Alert Aggregations can be defined based on the IoT Alert, related Device, or related Customer Asset.
Work with alert data
Out of the box, the Connected Field Service solution contains several actions and workflows that can be used to help with automating items like creating and registering devices and populating relevant data on records.
Some of the key actions related to IoT Alerts include:
| Display Name | Description |
|---|---|
| JSON-Based Field Value - Get Number | Reads a numeric property in the specified JSON object. |
| JSON-Based Field Value - Get String | Reads a string property in the specified JSON object. |
| JSON-Based Field Value - Get Boolean | Reads a Boolean property in the specified JSON object. |
The data in the Alert Data field is in the JSON format. The following text represents an example of what would be passed to the Alert Data field when an IoT Alert is raised.
{"deviceid":"smt-1298","readingtype":"Temperature","reading":113,"eventtoken":"c802338d-60f2-4a79-b45c-e164e2191ce0","threshold":70,"ruleoutput":"AlarmTemp","time":"2018-09-06T15:58:08.964Z"}
Generally, you can't directly use the contents of the Alert Data field because you might be looking to query based on one of the properties, not all of them. You must first parse out the relevant parameters that you want to work with, so you can use them to drive query on and drive next steps.
If we parse out the JSON string, we can see that it's communicating these parameters and values:
| Parameter | Value |
|---|---|
| deviceid | Smt-1298 |
| readingtype | Temperature |
| reading | 113 |
| eventtoken | c802338d-60f2-4a79-b45c-e164e2191ce0 |
| threshold | 70 |
| ruleoutput | AlarmTemp |
| time | 09/06/2018 06:58:08 AM |
To help with parsing out the specific parameter that you may need from the JSON string, you can use one of the JSON - Based Field Value actions.
The JSON - Based Field Value actions contain the following parameters:
| Parameter | Type | Description |
|---|---|---|
| JSON | Input | The JSON object to examine. (In this case the Alert Data field) |
| PropertyPath | Input | Property name or path of the value to ready. (Case-sensitive) |
| DefaultReturnValue | Input | Default value to return if specified property isn't found. |
| Response | Output | The response value for the property specified. |
Depending on the JSON - Based Field Value action, you specify the Output Parameter might be a text string (String), numeric value (Number), or Boolean value (Boolean).
For example: If you used to use the JSON - Based Field Value - Get Number action to extract the reading value for this Alert Data JSON string:
{"deviceid":"smt-1298","readingtype":"Temperature","reading":113,"eventtoken":"c802338d-60f2-4a79-b45c-e164e2191ce0","threshold":70,"ruleoutput":"AlarmTemp","time":"2018-09-06T15:58:08.964Z"}
It might look like this table:
| Parameter | Value |
|---|---|
| JSON | Alert Data (Field Name) |
| PropertyPath | reading |
| DefaultReturnValue | 70 (Represents the current temp threshold) |
| Value | 113 |
The value represents the value that the action returns, which in this case would be 113 since that is the value associated with the "reading" property. The reason we use the Get Number action, is so we can pass the value to a numeric field and then use numeric query options on the value to determine what to do with the item.
Practical application
Now, a look at a practical application of this concept.
Let's say that we have a Smart Thermostat that is registered as an IoT Device. If the reading on the alert exceeds 70 degrees, an IoT Alert is generated in CFS.
If the device reading is between 70 degrees and 85 degrees, have Connected Field Service automatically send a command to the device to reboot it.
If the device reading it is greater than 85 degrees, require a technician to do some manual troubleshooting.
We can accomplish this by creating a workflow that:
First executes the JSON -Based Field Value - Get Number action to capture the value of the "reading" property.
Next it writes the output value returned to a custom field on the IoT Alert record, for example, Device Reading.
Another workflow could be triggered on the update of the Device Reading field that does the following actions:
If the Device Reading field is between 70 and 85: It creates a Command related to the IoT Alert that sends a reset command to the device.
If the Device Reading field is greater than 85 degrees, the workflow will end with a status of succeeded.
Important
While the Connected Field Service solution includes the above-mentioned workflows and actions, many organizations do not use the Dynamics 365 Workflow functionality. Since it provides flexibility and a larger selection of services that it can work with, Many organizations will use Power Automate for parsing the JSON.
Use Power Automate
This same concept can be used with Power Automate. Instead of using the JSON-Based Field Value custom actions, we can use the Parse JSON action in the flow. When you trigger the Parse JSON action, the JSON from the Alert Data field is parsed into Individual Properties. The schema must be defined so the command knows how to parse the data. Sample payloads from the IoT Alert can be used to generate the Schema.
In the image, we used the same JSON string that was included in an IoT Alert to create the Schema:
{"deviceid":"nest1234","readingtype":"Temperature","reading":80,"eventtoken":"cfd5e690-ee88-4ca8-a75d-3b86ac61295c","threshold":70,"ruleoutput":"AlarmTemp","time":"2019-10-19T16:42:26.457Z"}
You can see that it created multiple properties that represent each item passed in the JSON such as the deviceid, readingtype, reading, etc.
Once the data has been parsed, it can be used to populate other fields in the IoT Alert just as we did with the workflow. Each property can now be used as dynamic content in any future step in the flow.
If we revisit our smart thermostat example from earlier, we can accomplish the same result by creating a flow in Power Automate that does the following actions:
First, the flow executes when a new IoT Alert record is created.
The Parse JSON action is executed to parse the JSON into individual properties.
Next, the flow updates the IoT Alert record with the output value of one of the returned properties. For example, the Reading property is used to update the Device Reading field.
Another flow could be triggered on the update of the Device Reading field that does the following actions:
If the Device Reading field is between 70 and 85: It creates a Command related to the IoT Alert that sends a reset command to the device.
If the Device Reading field is greater than 85 degrees, the workflow with complete with a status of succeeded.