Smarter Solutions for Smart Devices using Salesforce’s “Big Four” Stack
Smart devices of all types, models, shapes, and sizes are part of everybody’s life and routine. From mobile phones and smart watches to cars, robots, sensors, and many others communicate to each other and remote services, hosted in the internet. Communication between these types of devices is commonly known as IoT (Internet of Things). These devices commonly have a smaller size, reduced memory, limited storage, and CPU capacity. For communication, the most used protocol is MQTT (Message Queue Telemetry Transport), for its lightweight, pub/sub, machine to machine nature, designed for connections with remote locations that have devices with resource constraints or limited network. Management, monitoring, and maintenance of Smart IoT Devices can only be achieved by implementing smart solutions, and this is what this article us about.
Throughout this article, we will bring to light an end-to-end smart solution to Smart IoT Devices, leveraging the power of the Salesforce’s “Big Four”, namely Salesforce, MuleSoft, Slack and Tableau, we are going all the way through from ideation and design to implementation.
Salesforce’s “Big Four” as we refer to them in this article are outstanding and unbeatable platforms on their own, but when combined, they enable the creation of flawless, complete, best-of-breed, state-of-the-art solutions encompassing management, monitoring, integration, collaboration, communication and beyond.
Scenario
A fictitious company named EDUP develops generic Smart IoT Devices that make people’s lives better and happier. Their products are very robust and stable, but some components have limited lifetime and need replacement, which requires the visit of a technician. To provide a smart, smooth and holistic process to handle device failure and component replacement, EDUP would like to implement an end-to-end solution where the Smart IoT Devices can detect failures and automatically trigger the process to notify EDUP’s HQ so that a support case can be created, so that the dispatch team can communicate and collaborate with the technical team to have a technician assigned to execute the job. Throughout the lifetime of the job, communication and status changes should be communicated to all parts. At a more strategic and analytical level, the team would like to extract and visualize information to understand locations where these devices are deployed, who are their customers, what type of failure are more commonly happening and all sorts of analysis between, so that they can improve their products and services and ultimately, people’s lives.
Solution
Starting from a high-level view, let’s put together a diagram to illustrate how the different components that comprise the solution collaborate and what their role is. Based on Salesforce’s “Big Four”, this is what the solution looks like:
As we dive down into details of each requirement and functionality of the solution, we can picture their inner workings with the diagrams below as well.
Account & Product Registered Notification
Is triggered when the user registers the device and his own identification details such as full name, email address, home address, mobile number, etc. A notification containing these details is published and subscribed to by the MuleSoft application, which then makes calls to Salesforce to register the product and the consumer, respectively as Product and Account entities. These are then sent back to the Smart IoT Device, which updates the information label and keeps record so that if an issue occurs, EDUP’s central can quickly and easily be notified.
The Smart IoT Device here is simulated via a Windows Form application, which gets its status label changed according to the state of user and product registration and connected component. For this demo, the “component” is a simple USB peripheral (keyboard or mouse) that when connected “starts up” the Smart IoT Device.
The picture and animated diagram below illustrate how the data flow looks like for this type of notification:
Faulty Device Notification
Is triggered when the device executes a self-health check and identifies an anomaly, which could be for example a critical component that when expired or faulty requires a visit of a technician for replacement. For this article and accompanying demo, when the Smart IoT Device (Windows Form application) detects a disconnected USB device (again, either a mouse or a keyboard), that is reported back to EDUP’s central.
When these events happen, the device automatically emits a notification containing information regarding identification of both product and customer (account), date and time, plus a description of what the failure was (smarty, right?).
That is published by the device and consumed by the MuleSoft application, which then orchestrates a series of calls, first to Salesforce so that a ticket (Issue) can be created and then with the ticket (issue) number from Salesforce, the MuleSoft application broadcasts the message to Slack, Tableau and MQTT so that the dispatcher team receives a message via Slack to assign and dispatch a technician to visit the customer and resolve the issue, the Smart IoT Device can be informed (thus inform the customer) that the issue has been created and will soon be fixed and ultimately the Tableau data-source can be fed. The picture and animated diagram below illustrate how the data flow looks like for this type of notification:
Issue Escalated Notification
EDUP aims at ALWAYS making people’s lives better, if it takes too long for a technician to be assigned to resolve an issue, it would automatically be escalated or it would also be escalated when the Smart IoT Device stays in a faulty state for a certain period. An escalation event is triggered when the status of the Issue in Salesforce is changed to “Escalated”. When that happens, the MuleSoft application receives a notification of Salesforce object status changed and publishes a message to MQTT broker to that the Smart IoT device is notified and updates the label according and the dispatching and technician teams are aware of the Issue status change. Lastly, the data-source for Tableau dashboards, etc., gets updated as well and again, based on Salesforce’s “Big Four”, this is what the solution looks like:
Issue (Job) Assigned Notification
Either escalated or as part of a normal SLA, when an issue is ready to be assigned to a technician, the dispatching team can use the interactive notification in Slack to assign a technician to execute the job. When that happens, Slack calls a Webhook endpoint exposed via MuleSoft. The MuleSoft application then orchestrates a series of parallel calls to Salesforce, MQTT and Tableau with information regarding the new status and assigned technician as well as to Slack itself, so that the assigned technician receives all details to resolve the issue (complete job). This is what this part of the solution looks like:
Issue (Job) Execution Started Notification
To keep track of the time that it takes to complete a job and others, when the technician is about to start executing a job, from the Slack notification the technician can confirm the start of the execution. When that happens, Slack calls the Webhook exposed by MuleSoft. The MuleSoft application receives that request and broadcasts to Salesforce, MQTT and Tableau, so that all of these have the latest information regarding the job execution (status change). The screenshot and diagram below demonstrate how that looks like:
Issue (Job) Execution Resolved Notification
Yet again, our sagacious (smart) device keeps on checking for its own health state and once it identifies that the faulty component has been replaced and everything is working fine, it automatically publishes a message to MQTT broker notifying that and starting the process of marking the issue (job) as resolved. Like some (or most) of the above flows, the MuleSoft application subscribes to the message produced by the IoT device and broadcasts to Salesforce, Tableau and Slack, finishing the job. The screenshot and diagram below demonstrate how that looks like:
Tracking and Analysing Data in Tableau
With not only telemetry type of information being generated, but also lots of those with more of a business value, EDUP deploys Tableau for Data and Analytics, where information produced by the data flow in between interactions and executions can be viewed and displayed as per the examples below:
MuleSoft Implementation
To keep it simple and avoid getting too much into the nitty-gritty of technical implementation in MuleSoft, the following screenshot demonstrate the flows that comprise this application:
Conclusion
The result of putting in place a solution like this that leverages and brings together best of breed CRM, Communication, Collaboration and Data Analytics tools equates to healthier devices and happier customers on one end and on the other end, a more dynamic and competitive company, all of that powered by the most complete and powerful integration and API management platform — MuleSoft.
Author
Eduardo Ponzoni heads the integration practice as part of the Digital Engineering team of Datacom in Australia. Even though he plays a vital managerial, advisory and sales/presales role, he is very technical and still very much hands-on as an architect and developer. Eduardo holds several certifications and can be contacted on LinkedIn or email.
