Using IoT Explorer to Power Your Digital Transformation Projects

November 1, 2017

Hello IoT Explorer

Salesforce’s long-fabled Internet of Things (IoT) platform has finally become generally available in the Winter ‘18 release! I’ve had the pleasure of partnering with Salesforce behind the scenes during the development of its IoT offering. In this series of posts, I’ll help you get started with IoT Explorer, discuss design patterns for IoT use cases, and dive deep into IoT Explorer configurations to help you bring your prototypes to life.

New to IoT? Salesforce Trailhead has a nice IoT Basics module to get you up to speed with how the Salesforce perspective on IoT centers around digital transformation, by joining device data with customer context.

The evolution of a name

Salesforce initially demonstrated their IoT offering under the working name Thunder. In early 2017, the beta product was rebranded as IoT Scale, and the underlying platform retained the Thunder name. This is an important distinction. Thunder is a fundamentally different platform than the platform, powering the vast majority of Salesforce products.

IoT Scale was purpose-built to handle billions of events per day, generated by hundreds of thousands of devices. To achieve this kind of massive scale, Salesforce had to create a fundamentally new platform, and these clusters are not cheap. As IoT Cloud matured, lessons learned were ported to the platform using the platform-events architecture. IoT Explorer was born.

IoT Explorer is built on the platform, which means the power of Salesforce IoT is now available to everyone and to all org types — including developer editions — as part of the Winter ‘18 release. IoT Explorer can handle millions of events per day, which is plenty for most any prototype use, and for a lot of production deployments as well. Once you have a need for IoT Scale, the vast majority of configuration can be migrated between the two products easily.

Creating your first IoT Explorer orchestration

An orchestration is the combination of states, rules, actions, and transitions that allow you to use device-level event data to power your Salesforce applications. The Salesforce Trailhead on IoT Scale Edition Design and Rollout will give you a solid foundation with the terminology used in Salesforce IoT.

Our orchestration will power a simple proactive-ordering use case. We’ll monitor supply levels of a connected coffee machine, then take action when the coffee hopper is running low. Our action will depend on subscription status. If the coffee machine has an active subscription, we’ll create a case to refill coffee beans. If there is no subscription, we’ll create an opportunity to try and sell the contact a subscription.

While simple to start, this use case can be extended to cover a broad range of digital-transformation scenarios as your company looks for ways to shift from selling a product to providing services.

Prepare a Winter ‘18 Developer Edition for IoT Explorer

We can get pretty far using standard objects, so I’ll keep this demo as simple as I can while showing off what IoT Explorer can do.

    1. Create a new Winter ‘18 Developer Edition org
    2. Create an Account record: Universal Containers.
    3. Create a related Contact record: Dave Stanton.
    4. Add a custom field to the Asset object:
      1. Go to Setup.
      2. Open Object Manager.
      3. Click on Asset object.
      4. Add a checkbox custom field: Subscription.
    5. Create two Asset records:
      1. Both records should look up to the account and contact you previously created.
      2. One asset should have Subscription checked.
      3. Other asset should have Subscription unchecked.

Define a Platform Event

Platform events allow you to define the schema for an event within the platform. You can think of these events like temporary records that can power your workflows. New to event-driven architecture? Check out the Salesforce Trailhead Platform Events Basics module.

  1. Go to Setup.
  2. Search for Platform Events.
  3. Create new deployed platform named Coffee Hopper.
  4. Add a Level custom field:
    1. Type: Number
    2. Field Label: Level
    3. Field Name: Level
    4. Length: 18
    5. Decimal Places: 0
  5. Add an Asset Id:
    1. Type: Text
    2. Field Label: Asset Id
    3. Field Name: Asset_Id
    4. Required: true
    5. Length: 80

Enable IoT Explorer

IoT Explorer is available in all Winter ‘18 orgs, but you’ll first need to enable. You likely want to have Setup opened in one browser tab and Service opened in another tab. You configure the orchestration within Setup, but will need to see the resulting records created in Service Cloud.

      1. Go to Setup.
      2. Search for Salesforce IoT.
      3. Click on Getting Started.
      4. Click the switch to enable IoT Explorer.

Create a Context

A context is a 360-degree view of your customers. Contexts combine event data from devices with the rich customer data you store in Sales and Service clouds — accounts, contacts, assets, opportunities, and cases.

      1. Go to Setup.
      2. Search for Contexts.
      3. Create a new Context:
        1. Name: Coffee Hopper Context
        2. Key Type: String
        3. Salesforce Object: Asset
        4. Object Key: Asset ID
      4. Add a platform event to the context:
        1. Context: Coffee Hopper Context
        2. Platform Event: Coffee Hopper
        3. Key: Asset Id

Build an Orchestration

An orchestration is where you design the state machine. The state machine combines the different possible states for a device (e.g., Normal, Warning, Fault) along with rules that should trigger a transition between states. We want to transition states based on the level of the coffee hopper. Once the level falls below 40 percent, we’ll consider the device to be in a warning state. Once the level falls below 10 percent, we’ll consider the device to be in a fault state.

      1. Go to Setup.
      2. Search for Orchestrations.
      3. Create a new Orchestration:
        1. Name: Coffee Hopper Orchestration
        2. Context: Coffee Hopper Context
      4. Create additional states:
        1. Click Add State
        2. Again click Add State
        3. Rename your states by clicking on the text labels:
          1. Green: Normal
          2. Red: Fault
          3. Purple: Warning
        4. Click the ellipsis for the Warning state:
        5. Click Move state up so that our states and colors are in a more logical sequence
      5. Add transitions to your states:
        1. Normal
          1. When: Coffee_Hopper_e
          2. Condition: Coffee_Hopper__e.Level__c < 40
          3. Transition: Warning
        2. Warning
          1. When: Coffee_Hopper_e
          2. Condition: Coffee_Hopper__e.Level__c < 10
          3. Transition: Fault
        3. Fault
          1. When: Coffee_Hopper_e
          2. Condition: Coffee_Hopper__e.Level__c < 90
          3. Transition: Normal
      6. Click Save
      7. Click Activate.
      8. Check the box to Delete all existing orchestration instances.
      9. Click Activate.

You now have a functioning orchestration! Here is a screenshot of our first state machine:

Testing Your Orchestration

You cannot create platform events through in the way you create object records, so we’ll need to use the Salesforce REST API to create events to test our orchestration. You don’t need any prior experience with Salesforce APIs to continue, but you might want to review the Salesforce Trailhead module API Basics for reference.

      1. Keep your orchestration rules open in a browser window.
      2. Open in new browser window.
      3. Login to Workbench:
        1. Environment: Production
        2. API Version: 41.0
        3. Check the I agree to the terms of service checkbox
        4. Click the Login with Salesforce button
      4. Click the Utilities tab.
      5. Click the REST Explorer link.
      6. Send event data:
        1. Click the POST method radio button
        2. Update the base url to be /services/data/v41.0/sobjects/Coffee_Hopper__e
        3. Request Body: { “Asset_Id__c”: “abc123”, “Level__c”: 100 }
        4. Click the Execute button
        5. Look in the response information to ensure you see success: true
      7. Go back to your orchestration browser window.
      8. Click on the Traffic tab within the orchestration page.
      9. Confirm you have one instance in normal state.

Success! You know have a functioning orchestration with a registered instance. Let’s go through an example lifecycle of a coffee hopper by sending different request bodies:

      1. The hopper reaches a warning level: { “Asset_Id__c”: “abc123”, “Level__c”: 30 }
      2. Look at the traffic view to watch your existing hopper instance transition to a Warning state.
      3. The hopper reach a low level: { “Asset_Id__c”: “abc123”, “Level__c”: 9 }
      4. Look at the traffic view to watch your existing hopper instance transition to a Fault state.
      5. The hopper is refilled: { “Asset_Id__c”: “abc123”, “Level__c”: 100 }
      6. Look at the traffic view to watch your existing hopper instance transition back to a Normal state.
      7. Register a second instance: { “Asset_Id__c”: “def456”, “Level__c”: 100 }
      8. Look at the traffic view to see a new hopper instance created in a Normal state.

Stay tuned!

We’ve gone through a lot of material in a short time, but you now have a reusable baseline for proactive use cases. In subsequent articles, we’ll discuss design considerations for state machines and expand our orchestration to create cases and opportunities based on event data.

Previous Article
Expanding Your IoT Explorer Prototype
Expanding Your IoT Explorer Prototype

By Dave Stanton In a previous blog, we created a base IoT Explorer orchestration, and spent some time discu...

Next Article
Salesforce and Amazon Pay Integration
Salesforce and Amazon Pay Integration

By Rashmi Chauhan Amazon Pay provides a convenient way to pay for purchases online. Integrating Amazon Pay ...