Effective Declarative Automation Strategy in Highly Complex Salesforce Environments

With the increased prevalence of flows for automations in many (at least the well-built) organizations there needs to be an increased focus on a thoughtful strategy and approach for appropriately architecting to effectively address organizations with complex automation requirements.? Flows have the ability to scale with the largest, most complex organizations but many are unaware of the full potential that flows bring to the table.

I am not a coder and know those who love to write APEX code are thinking through and quoting Flow limitations like 100 Total SOQL queries issued or 10k total number of records processed as a result of DML statements or have experienced Flow timeouts (10k milliseconds) and are convinced that Flows cannot scale to meet full organizational needs.? There are declarative approaches to get through these and many other Flow limitations.?

Complexity in Automations:

Beyond the pure Flow limitations, there are other indicators that you may be managing a highly complex Salesforce organization.? From an automations perspective, there are two scenarios that highlight the complexity that many organizations face with automations: Cascading Actions and Many-to-Many Actions.

Cascading actions are when a single trigger creates changes across a series of records.? For example, a change on an account can trigger changes on opportunities and those changes on opportunities can create downstream changes on orders, assets, etc.

With cascading actions there is obviously increased complexity when downstream actions have conditionality to them (those actions don’t always occur).? For example, account information changes and only accounts of a certain type trigger downstream changes or only open opportunities are changed based upon the changes to account.?

There are also increased stresses placed on your flow limits when one-to-many relationships exist.? For example, one account has multiple opportunities, each of those opportunities has multiple orders or assets, etc.

Many-to-Many Actions are where multiple triggers can drive multiple actions and any given action may be driven by multiple triggers.? In our examples below, Trigger A only creates Action #1. Trigger B creates Actions #1, #2 & #3 and Trigger C create Actions #2 & #3.? ?This situation also faces increases in complexity when conditionality is present.? For example: Trigger B always results in Action #1 & #2 but only under certain conditions creates Action #3.

The most complex organizations have a compounding of Many-to-Many Actions and Cascading Actions with conditionality throughout.? So, in the following example: Trigger B will create Action #2 in certain situations, Action #2 will drive changes on Object B in certain situations and Actions on Object B will drive changes on Object C in certain situations.

Many of you have already experienced the challenges of this level of complexity in automations.? If you have not experienced this type of complexity in your organizations, you likely will as your organization matures and continues to expand automations.?

What Do You Do:

At this point we have agreement on the problem but how do you get toward a solution?? The first thing that you need to do is shed the conventional wisdom for less complex orgs that say things like “No more than 3 flows per object” or “Build only one flow to do everything”.?? This simple guidance may work well for less complex orgs but likely won’t meet your needs.

?

Step #1: Defining the Need

To get going, get a piece of paper, a clean white-board or a useful flowcharting tool (ex visio, lucidchart, etc.) and start listing out the triggers and the actions, including all of the conditionality for those actions in your organization.? Fortunately, most to all of this information already exists in your organization in your existing Flows, Process Builders, Workflows and/or APEX (that horrific 4 letter word again).

Keep this exercise simple and straightforward.? For triggers, you are listing out the objects where the triggering events occur and the conditional under which they occur (ex Account, active box gets unchecked).? For your actions, this can be as simple as a change of a single field or can be grouping of changes that occur under the same conditions.

As you progress through this activity you can likely organize your efforts into the various objects where your automations reside with all of the triggers and actions that are encompassed within those objects.? You will likely end up with something like this…

?

Step #2: Understanding Platform Events

The second step to tackling automations in your highly complex org is to learn about Platform Events.? As you would expect, there is great information on Trailhead to learn about Platform Events (https://trailhead.salesforce.com/content/learn/modules/platform_events_basics).? Ignore the references to APEX coding in the Trailhead.? Just trust me, you don’t need to code for this!

Platform Events are a system where there are Event Producers, an Event Bus and Event Consumers.? The Event Bus is essentially a repository for Platform Events (think about Platform Events as actions/records that are not directly tied to a given object or field but an action/record that can be accessed universally across Salesforce.? Event Producers create events that are placed on the Event Bus.? Event Consumers “listen” for specific events on the bus then take action.

Starting to use Platform Events is easy in Salesforce.? Yes, you guessed it, just go into Setup and Search on “Platform Events”.? It will pop up under Integrations (don’t worry about this we aren’t using it for integrations).? On Platform Events, click “New Platform Event”.? We named our Platform Event, “Platform Triggers”.? Once in your new Platform Event, you can create multiple Custom Fields & Relationships.? For this use, we created fields called:

·???????? Event Details

·???????? Source Object

·???????? Source Record ID

·???????? Source Record Name

·???????? Status

·???????? Target Object

·???????? Target Record ID

·???????? Triggering Automation

·???????? User Triggering Event ID

Our resulting Platform Event looked like this…

Key Concepts

Now, here is a key concept to understand.? For this use, the Triggers that you identified in Step #1 are going to be Event Producers in that those triggers will create one or more Platform Events.? The Actions that you identified in Step #1 are Event Consumers in that they will drive changes in one or more records.? What you are building is an event driven automation architecture that can flexibly address the many-to-many relationship between triggers and actions within your organization.

Another key fact is that Flow is designed to both create and be triggered by Platform Events.? Creating a Platform Event is like creating any other record using Salesforce Flows.? Once you have created your Platform Event, that event becomes a selectable object for creation of new records.

In our below diagram, we were looking to create Platform Events for multiple CMQS (custom object) records that we were looking to changed based upon a single triggering event/record.? Each of those records will be subsequently changed based upon a flow that is triggered by the Platform Event that was created.

The build for creating our Platform Events is likely very similar to other Flows you have built that create, update or delete multiple records.? It starts with gathering all the records that you are looking to create, update or delete.? Then, for each record, you will be assigning all the variables needed to populate and subsequently drive your platform event.? The values from the initial assignment are then added to a collection variable.? Your loop proceeds with all the Platform Event records to be created then, once all have been defined and added to your collection variable, you leave the loop and create the records.

On the other side of the Event Bus are Flows that are Triggered by Platform Events.? This is a common Flow type, although most are just beginning to understand the potential for these Flows.? For these Flows, you simply define the Platform Event that will trigger the Flow (As of the writing of this article there is not the ability to Set Entry Conditions for Platform Events.? That means that you will need to put a decision branch after the trigger to handle conditionality when the flow kicks off.)

Within this platform event triggered flow, you define all of the actions (creating, updating deleting of records) to be performed.?

Step #3: Start Your Build

Now that you have an aggregate understanding of your needs and have built your initial Platform Event(s), you can start with the revised build of the automations in your instance.? You understand the end goal/architecture so just take this one step at a time.

As you are building you will begin to see some of the tradeoffs in specific design of your event driven automations architecture.? The biggest tradeoff occurring when defining the Platform Events and details within those events.

Let’s go back to that org view that you had previously created.?

In this instance there are several different ways that this automation system can be architected.? As an example, let’s take Trigger E on the Opportunity and, for example purposes, say that is the Opportunity Stage moving to a “Closed” stage type.? In this case, we have previously identified that there are two actions (#4 and #6) that we want to take when our Opportunities move to “Closed”.? We have also defined that Triggers A, B and C also drive actions that subsequently hit Trigger E.? We have also defined that after Action #6 is triggered, Trigger H fires and creates actions #7 and #9.? Yes, there is a lot going on here.

There are two different ways to construct your Platform Events: Trigger or Action based.? If you build your Platform Events as Trigger based, your trigger flow would create a Platform Event that essentially say “Trigger E” occurred.? You would then have one or more flows that are monitoring for the creation of a “Trigger E” Platform Event and would execute when the right Platform Event is created.

If you are building your Platform Events as Action Based, your triggering flows would create one or more Platform Events based upon the Actions that you are looking to occur.? Then, on the action side, you would have a single flow for each of the actions that you want taken.

For both Trigger or Action based Platform Events, you can have actions that also create subsequent Platform Events and are therefore triggering the next automation on the next object.

It is important that you recognize the options for build that exist.? There are, of course, tradeoffs in both approaches that should be evaluated for your specific business situation.?

Step #4: Building Tracking into Your System

There are generally two different capabilities that we recommend for tracking of automations throughout your system.? These will help provide tremendous insights in understanding what happened or didn’t for given business situations or when issues arise.

The first thing that we recommend is building a field, “Automation Making Update” onto each of the objects where your automations are making changes.? Each time an automation makes an update to a record, information on that automation should be written to that record.? Specifically, the information written should include the name of the Flow that is changing the record and the source record that kicked off the flow.? There can be other details included if they can be fit into the text field.? This field should then be added to history tracking for all of the impacted objects.

The second thing that we recommend specifically deals with tracking of the Platform Events that are created.? One downside of Platform Events is that Salesforce does not capture and allow reporting on Platform Events.? We recommend the creation of a custom object for Platform Event Tracking.? This object should have a new record written to it each time a Platform Event is created (as you know, that is a simple flow to build).??

Conclusion

With good thought around architectural design with respect to your specific business needs, platform events offer many opportunities to improve the overall automation architecture in your organization.? We would love to hear your thoughts and or feel free to reach out with any questions.