Automate This! — Discover How to Use the Well-Architected Framework to Build Automation

Welcome to another “Automate This!” In this live-streamed video series, we cover all things automation, from use cases and best practices to showcasing solutions built by #AwesomeAdmin Trailblazers like you. Automation allows you to remove manual tasks, drive efficiency, and eliminate friction and redundancy. In this episode, let’s see how Melissa Shepard uses a combination of synchronous and asynchronous automation patterns to automate an order entry process that includes inventory checks and generating invoices in an external enterprise resource planning (ERP) system. Melissa will walk through the use cases for both synchronous and asynchronous automations and show how to use them both within Flow. Additionally, we’ll cover automation best practices and talk about how synchronous and asynchronous patterns align with the Salesforce Well-Architected framework.

Use cases for synchronous and asynchronous patterns are important to understand as you design your automations because they can affect performance, scalability, and user experience. The key differences between the two: Synchronous automations execute immediately in response to some type of state change within the system (that is, a user running a flow, a change made to a record, etc.), and will execute as a single, unstopped sequence of steps until they’re completed. Conversely, the steps in asynchronous automations won’t necessarily run or return a response immediately.

Use cases for synchronous processes

The most common use case for a synchronous process is one that requires some type of user input (that is, a screen flow). In this scenario, a user provides information, the automation runs, and a response returns back to the user once everything is completed. In our demo, we cover an order entry process that requires the user to select products and request the external system to do an inventory check in real time to make sure there are sufficient quantities available before the order can complete. This is a good use case for a synchronous process since user interaction is required to complete these steps.

Use cases for asynchronous processes

Asynchronous processes, in contrast, contain steps that can run without user interaction and typically run via record-triggered automations. The most common use case for an asynchronous process involves sending a message to an external system. In this case, the system called will likely need to do some additional processing once it receives the message. Since we don’t know whether or not the system will be able to process the message right away, we don’t want to keep the user who initiated the process waiting for a response, which could take a while to come back. The example in our demo features a callout to an ERP system that occurs after an order is placed. The ERP system that receives the callout needs to create an invoice, which may or may not happen immediately upon receipt of the message. The system can still send a response back to Salesforce when that work is complete, but it wouldn’t be efficient for the Salesforce user who entered the order to wait on the order screen for an external system to finish its processing. Instead, once the callout has been made, the user can move on to something else and use a report to view the updated order status later.

Performance and scalability benefits

Using asynchronous processing where possible can help minimize performance bottlenecks since asynchronous steps can execute in parallel. This helps account for scenarios such as retail organizations seeing seasonal spikes in the volume of orders placed simultaneously. Asynchronous processing also allows your organization to scale its IT landscape since external callouts can be sent to an event bus, which is a structure that can allow multiple systems to communicate through a shared set of interfaces (APIs). Multiple target systems can “listen” to the event bus for updates from a source system and process them accordingly. For example, if we wanted to expand the order entry scenario from our demo, we could say that instead of only needing to communicate with a single ERP system, our automation also needs to send the same updates to an inventory management system, an accounting system, and another Salesforce org. If the asynchronous step in our automation sent a message to an event bus, all of those systems could simply subscribe to messages from our Salesforce org to receive any order updates that get sent out. You can think of subscribing to messages in a similar way as subscribing to a newsletter or email updates from a company whose products you’re interested in. The company sends updates out to all subscribers, who can then choose what to do with those updates when they’ve received them. This eliminates the need to make changes to the automation itself if any additional systems ever need to receive the message in the future. See the Architect’s Guide to Event-Driven Architecture on the Salesforce Architects website for additional information.

The right tool for the right job

You may encounter some scenarios where you determine that a process needs both synchronous and asynchronous steps. This won’t be a problem at all. You can build an automation like that by adding an asynchronous path to a record-triggered flow and then adding steps to each path (the default path is synchronous). In flows that contain both types of steps, the ones in the synchronous path will execute first, followed by the ones in the asynchronous path. Understanding the use cases for these two patterns, along with how and when to use each one, will allow you to design high performing, scalable automations with optimal user experiences.

In this demo we’ll show the flow of data between Salesforce and an ERP system for creating a new sales order. This will involve both synchronous and asynchronous automation.

Process of creating an order and syncing with an ERP system

A salesperson creates an order and adds products (Order Products) to the order. On the order record, the salesperson uses a “Check ERP Inventory” quick action that launches a flow to perform some synchronous operations, which checks inventory in another system in real time for each product and updates the “ERP quantity” custom field on each Order Product.

This is the Quick Action record.

Check the inventory in the ERP system in real time (synchronously)

In our flow, we use an HTTP Callout action (Beta), which creates an external service to get the inventory from the ERP system for each Order Line Item synchronously so the salesperson can confirm the order. An external service converts an external web service into an invocable action that can be used with a tool such as Flow Builder. This allows admins to connect to systems outside of Salesforce that have REST APIs by using OpenAPI standards without having to write any code.

This process will block the salesperson from doing anything else until the inventory is confirmed.

Confirm the Order Product inventory and create the ERP order (asynchronously)

When the inventory is confirmed, the order status changes to “Inventory Verified.” This same flow creates a platform event record that the external system subscribes to, which tells the ERP system to create the inventory order and deduct the quantities from product inventory. This should execute right away so the product inventory doesn’t get sold to another customer while the order is taking place in Salesforce. The platform event enables the order to create in the ERP system asynchronously after the salesperson has confirmed the inventory synchronously and closed the screen. Using a platform event allows the salesperson to perform other actions and navigate to other screens while this is being done, so they can perform other work without having to wait for the ERP system to create the inventory order.

This is the platform event configuration to create the ERP order.

Typically, you would send just the Order ID, and a tool such as an enterprise service bus (ESB) could query back to Salesforce for all associated Order Line Items for that order.

Confirm the order

The salesperson now changes the order status to “Confirmed.” Another record-triggered flow executes when the order status is set to “Confirmed.”

This flow has two paths:

• A synchronous path that creates a custom notification to let the salesperson know that the invoice is now being created in the ERP system.
• An asynchronous path that creates a platform event that the ERP will subscribe to in order to create the invoice. By putting this on the asynchronous path, it will tie up less system resources and execute after the custom notification is created.

This is the Start element for the flow. It starts on the Order object when the record is updated and the order status is set to “Confirmed.”

This is the configuration for the Create ERP Invoice platform event.

Send ERP Invoice generated notification to Salesforce

For the demo: We’ll use Anonymous Apex to create a platform event that flow subscribes to in order to mimic ERP coming back to tell Salesforce that the invoice has been generated.

// Create event instance.
ERP_Invoice_Generated__e event = new ERP_Invoice_Generated__e(Order_ID__c =’order id’,
Order_Number__c =’order number’);

// Publish event.
Database.SaveResult sr = EventBus.publish(event);

// Inspect publishing result for each event
if (sr.isSuccess()) {
System.debug(‘Successfully published event.’);
} else {
for(Database.Error err : sr.getErrors()) {
System.debug(‘Error returned: ‘ +
err.getStatusCode() +
‘ – ‘ +
err.getMessage());
}
}

A platform event-triggered flow subscribed to the ERP_Invoice_Generated__e platform event creates another custom notification to let the salesperson know that the invoice has been generated in the ERP system and will update the order status to “Ready for Payment” based on the total amount of the invoice.

This is the platform event-triggered flow.

Order finalized

The payment can now be made within Salesforce based on the invoice, and the order can be finalized.

Resources

• Salesforce Architects: Well-Architected: Automated
• Salesforce Architects: Event-Driven Architecture
• Trailhead: Automate Your Business Processes with Salesforce Flow