![\"\"](\"https:\/\/realintelligence.com\/wp-content\/uploads\/2019\/12\/1_BH1DZHkQN7-rgEHrsa3R1g-1024x228-1.jpeg\")
<\/figure>\n\n\n\nDefining these 4 types of processes gives us a framework for classification and a model for maintainability. For each object in Salesforce you will now have only these 4 types of processes in Process Builder. So in future, if the business asks for some change or action to occur when a new Contact record is created, I immediately know I can find the *contact_initiator<\/em> process and make my changes there.<\/p>\n\n\n\n Lets look closer at how these four process types can be used.<\/p>\n\n\n\n These are the most straight forward of the four process types because the state in which they execute is always when a new record is created.<\/p>\n\n\n\n To ensure this is the case when creating an initiator process check the \u201conly when a record is created\u201d option on the initial process event. Strict adherence to this principle would mean you only have a single initiator process per object in your Salesforce Org.<\/p>\n\n\n\n Within your initiator process your primary IF statements (criteria nodes) should identify major differences in the object\u2019s type. It may delineate between the object\u2019s record types, or between some primary categorisation of the object. For example, it might be important to your business to differentiate between the channels a Case is created through. In which case your criteria nodes for a *case_initiator<\/em> process may be each Case Channel e.g. Phone, Web, Email, Social, Chat (See Figure 6).<\/p>\n\n\n\n You may design your primary IF statements to be more complex by using two or more fields, for example \u2018IF Channel = Email AND RecordType = Technical Complaint\u2019. Be sure not to over complicate the criteria node statements, your process should be easily readable and match how the business organises the object. In this example step 3 only executes if the Case Channel is \u2018Email\u2019 and the Case Product is \u2018MP3 Player\u2019. Where you may have a number of actions that are not record updates, or occur in multiple action groups, you may want to design them as a subprocess and invoke them from each action group branch (more on these later).<\/p>\n\n\n\n Note that if you create scheduled actions you do not get the \u2018Evaluate next criteria\u2019 option. This makes your criteria filters mutually exclusive. Only one action group will execute for any new record. To avoid confusion you should ensure the criteria (primary IF) statements you define are always mutually exclusive regardless of if you use scheduled actions initially or not. This allows you to add scheduled actions in the future if necessary without major upheaval to your processes.<\/p>\n\n\n\n An exception to this rule is only viable in the first action groups as IF statements are executed in order. Sometimes it is necessary to take default initial actions for every new record created. So you may use the \u2018Evaluate next criteria\u2019 action group outcome within the first IF statement often coupled with the \u2018No criteria \u2014 just execute the actions!\u2019 condition.<\/p>\n\n\n\n In this way you can design your initiator process to segment the new records based on clear, primary filters (e.g. Channels and Record Types) so that your process is easily understood. Once segmented by the primary filters a process can conditionally automate different actions based on specific features of the newly created record.<\/p>\n\n\n\n Processors define the key stages of your business process. These should be the easiest to understand and possibly the most frequently used.<\/p>\n\n\n\n Processors should have one action group defined for each stage of your business process. Your criteria nodes statements should simply determine if the stage or status field is X and should use the advanced option to identify execution \u2018only when the specified changes are made to the record\u2019.<\/p>\n\n\n\n Simplistically this process says IF the stage has changed to X THEN do Y.<\/p>\n\n\n\n Often this process maps directly to a picklist field on an object. For example the Opportunity object often uses the Stage field to track the progress of an opportunity from initial qualification through to won or lost (See Figure 10). Often business rules are defined at each stage to validate if the opportunity is ready to progress and executives are possibly alerted if the opportunity changes stage and meets certain criteria (e.g. a big deal alert).<\/p>\n\n\n\n This pattern is very common in Salesforce applications. We see it in many use cases such as job candidates progressing through interview stages, events through planning stages, submissions through review stages, or projects through maturity stages.<\/p>\n\n\n\n Salesforce Path is often used in conjunction with a processor process. Path provides visual feedback and detail to a user viewing a record to see the current status of the record and the next steps required to progress the record to the next stage. When a user completes the required actions and updates the record status the processor process should fire.<\/p>\n\n\n\n Common actions that occur in the processor process are submitting the record for review, alerting relevant people, and updating associated records or fields.<\/p>\n\n\n\n Typically you only want any actions to occur once when the record enters the new stage, for this to occur you want to select the \u2018execute the actions only when specified changes are made to the record!\u2019 option in the criteria node.<\/p>\n\n\n\n As processors map to key business processes, organisations are often interested in identifying opportunities for process improvement. As a result it is a good idea to plan for detailed reporting requirements on these processes. Organisations often want to report on:<\/p>\n\n\n\n By reporting on this type of information organisations can identify bottlenecks and inefficiencies in their business processes, understand the behaviour of the system, or spot exceptions that need immediate attention. To enable this type of reporting we need to capture the history of transitions over time, not just the current state.<\/p>\n\n\n\n There are a couple of ways we can do this, the simplest is to add a timestamp field for each stage in the process, we can then update the timestamp when we complete that stage. This method has limitations if we allow the process to move forward and backward as the timestamps will be overridden and our reporting won\u2019t match what actually occurred.<\/p>\n\n\n\n The best method is to enable Field History Tracking on the object, then select the field that is used to track the state of the process. Now modifying the state will add an entry to the History related list. All entries in the History related list will include the date, time, nature of the change, and who made the change. This allows for the level of reporting most organisations are looking for. Note the field history data is only retained for up to 18 months within Salesforce.<\/p>\n\n\n\n So what if an object needs more than one processor?<\/p>\n\n\n\n It is common for business requirements to necessitate multiple processors for an object. An example here might be Cases, we often see a processor to track the Cases current status #case_process_status<\/em> and a processor to track the Cases current priority #case_process_priority<\/em>. The execution of one may even indirectly invoke the other.<\/p>\n\n\n\n Another scenario is when an object has Record Types that dictate two different processes. Be more careful in this scenario, your goal should be to minimise the number of processors per object without losing readability. So, if there is a lot of overlap between the two processes (they have common states) then consider condensing the design into a single master processor, but if they are largely independent, then separate them.<\/p>\n\n\n\n We advocate the use of multiple processors per object where necessary, however a good architect should always be looking for ways to minimise their propagation.<\/p>\n\n\n\n Finally, like initiators, processors should be designed with mutually exclusive action groups. Avoid using the \u2018Evaluate next criteria\u2019 option wherever possible, as a record may only be in one state at any time it should not be relevant.<\/p>\n\n\n\n Action processes are our catch all. All ad-hoc or independent automations should be modelled in the actions process.<\/p>\n\n\n\n Ideally we have one action process per object. Within the process each action group will be independent and here you should use the \u2018Evaluate next criteria\u2019 option as default. Think of the action process less like a process and more like a list of rules. We just bundle all the rules into a single \u2018bucket\u2019 we call the action process.<\/p>\n\n\n\n Generally the action process will execute tasks that occur once some manual action has occurred. Like when a record owner changes \u2014 alert the new owners manager and the old owner, or when one object is linked to another \u2014 update a counter on the parent, or if a value exceeds a limit \u2014 post a notification to chatter.<\/p>\n\n\n\n More advanced use cases can start using the confidence scores from Einstein to automate actions. Using Einstein in your processes makes your processes smart \u2014 meaning you are no longer hardcoding the rules into the process.<\/p>\n\n\n\n For example it\u2019s possible to build a process that leverages Einstein Lead Scoring to route and prioritise your leads. Einstein Lead Scoring uses artificial intelligence to score your leads by how well they fit your company\u2019s successful conversion patterns; so you don\u2019t need to know which characteristics indicate a high priority lead, you don\u2019t need to build a matching algorithm into your process, and you don\u2019t need to modify the characteristics as they change \u2014 because Einstein will automatically and accurately do this for you based on the history of all previous leads!<\/p>\n\n\n\n This can all be achieved in a single action group within the object actions process.<\/p>\n\n\n\n Action processes become more complex when you add scheduled actions. To add scheduled actions you\u2019ll need to have checked the \u2018execute the actions only when specified changes are made to the record?\u2019 option on the criteria node.<\/p>\n\n\n\n As action groups are assessed in order you can place all action groups that include scheduled actions at the bottom of the process. Note again that these are mutually exclusive, so ensure your criteria logic is sound.<\/p>\n\n\n\n Subprocesses are simply processes that are invoked by other processes. When creating a new process choose \u2018It\u2019s invoked by another process\u2019 from The process starts when<\/em> drop down list.<\/p>\n\n\n\n There are many uses for subprocesses, they are far more than just a convenience. Typically employed for reusability, by bundling business logic into a subprocess, you can then call them anytime you need. This avoids rewriting the same logic in many places.<\/p>\n\n\n\n In her blog<\/a> Jenwlee gives a nice overview of DRY (Don\u2019t Repeat Yourself) principles using Process Builder subprocesses. The goal here is to increase maintainability and convenience by abstaining from duplicating logic actions in multiple action groups.<\/p>\n\n\n\n A common example is a subprocess that first checks a customers preferred contact method before sending notifications. This can then be executed from any object that has a relationship with Contacts. In this way the primary process decides when to notify the contact but outsources the logic of how to contact the customer (i.e. via email, sms, communities chatter message) to the subprocess.<\/p>\n\n\n\n Subprocesses also enable nested IF statements. So, a processor may invoke a subprocess when the state of an object changes, the subprocess can then further break down which actions to take. For instance we may only notify a manager if we are in state X and the value is above Y. Using subprocesses in this instance allows us to keep the criteria in our processor pure by maintaining its granularity at the \u2018check for current state\u2019 level, and then provide finer granularity logic (value is above Y) in the subprocess.<\/p>\n\n\n\n Note you can\u2019t call scheduled actions in a subprocess so it cannot be used as a workaround to make action groups with scheduled actions compatible (non mutually exclusive).<\/p>\n\n\n\n Finally it is worth highlighting that you can call the same subprocess multiple times within the same action group. This feature can be very handy when you need to execute repetitive actions with slight changes. Think sending notifications to multiple people or updating multiple related records. Because immediate actions are executed in order (top to bottom), you can prepare the data then call the subprocess repetitively.<\/p>\n\n\n\n A more productive way of doing this may be to call a Salesforce Flow subprocess, rather than a Process Builder subprocess. The final best practice for subprocesses would be to ensure you use the right tool for the job, so we encourage you to get an understanding of Flow too as it is way more efficient at achieving some tasks that seem clunky in Process Builder.<\/p>\n\n\n\n Salesforce Process Builder is a very powerful tool for automating business actions. Thinking of Process Builder as a state machine execution engine is a more accurate way of understanding how it models business processes, despite it\u2019s name (a common problem for \u2018Salesforce\u2019).<\/p>\n\n\n\n Following the simple patterns outlined by the four process models above will ensure you are on the right path to developing maintainable and therefore more agile processes. As with any framework there may be situational exceptions that arise, but an understanding of these practical concepts will aid your thinking and solution design.<\/p>\n\n\n\n Have fun process building!<\/p>\n\n\n\n This is an exert written by and published on MEDIUM<\/a><\/p>\n\n\n\n Enough with the introductions, for the rest of this post we will look at the best practices and recommendations. Applying these to your Process Builder processes ensures they will be readable and easily maintainable. The declarative nature of Salesforce lends itself to fast and agile development. Especially when we are modelling business processes that often […]<\/p>\n","protected":false},"author":1,"featured_media":782,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[7,11],"tags":[],"_links":{"self":[{"href":"https:\/\/realintelligence.com\/wp-json\/wp\/v2\/posts\/781"}],"collection":[{"href":"https:\/\/realintelligence.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/realintelligence.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/realintelligence.com\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/realintelligence.com\/wp-json\/wp\/v2\/comments?post=781"}],"version-history":[{"count":0,"href":"https:\/\/realintelligence.com\/wp-json\/wp\/v2\/posts\/781\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/realintelligence.com\/wp-json\/wp\/v2\/media\/782"}],"wp:attachment":[{"href":"https:\/\/realintelligence.com\/wp-json\/wp\/v2\/media?parent=781"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/realintelligence.com\/wp-json\/wp\/v2\/categories?post=781"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/realintelligence.com\/wp-json\/wp\/v2\/tags?post=781"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Initiators \u2014 How to guarantee a consistent foundation<\/h1>\n\n\n\n
![\"\"](\"https:\/\/realintelligence.com\/wp-content\/uploads\/2019\/12\/created.jpeg\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/realintelligence.com\/wp-content\/uploads\/2019\/12\/stages.jpeg\")
<\/figure>\n\n\n\n
For further specification of record updates, secondary IF statements can be used. Each update can then optionally execute if it meets certain criteria. For example once you know the Case has a channel of Email, you could design a process to take three further actions (one always executes and two are conditional):<\/p>\n\n\n\n![\"\"](\"https:\/\/realintelligence.com\/wp-content\/uploads\/2019\/12\/record-Updates.jpeg\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/realintelligence.com\/wp-content\/uploads\/2019\/12\/conditional-1.jpeg\")
<\/figure>\n\n\n\nProcessors \u2014 how to engineer order amongst the chaos<\/h1>\n\n\n\n
![\"\"](\"https:\/\/realintelligence.com\/wp-content\/uploads\/2019\/12\/initiator-1.jpeg\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/realintelligence.com\/wp-content\/uploads\/2019\/12\/path-1024x202-1.jpeg\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/realintelligence.com\/wp-content\/uploads\/2019\/12\/one-at-a-time.jpeg\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/realintelligence.com\/wp-content\/uploads\/2019\/12\/report.jpeg\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/realintelligence.com\/wp-content\/uploads\/2019\/12\/field-History.jpeg\")
<\/figure>\n\n\n\nActions \u2014 how to remove the risk of human error<\/h1>\n\n\n\n
![\"\"](\"https:\/\/realintelligence.com\/wp-content\/uploads\/2019\/12\/next.jpeg\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/realintelligence.com\/wp-content\/uploads\/2019\/12\/confidence-score.jpeg\")
<\/figure>\n\n\n\nSubprocesses \u2014 how to simplify the complexity<\/h1>\n\n\n\n
![\"\"](\"https:\/\/realintelligence.com\/wp-content\/uploads\/2019\/12\/1_n77qD46nx7ggZsBumApDrw.jpeg\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/realintelligence.com\/wp-content\/uploads\/2019\/12\/sam-process-twice.jpeg\")
<\/figure>\n\n\n\nSummary \u2014 go forth and automate<\/h1>\n\n\n\n
Alex Peatti<\/a><\/h2>\n\n\n\n
I use technology to make people better at their jobs & run the Growth Solutions Engineering team at Salesforce.<\/h4>\n","protected":false},"excerpt":{"rendered":"