workflows

  • What is the difference between Process Builder and Workflow?

    Recently the Force.com Developer certification was retired, and all certificate holders were encouraged to switch to the Platform App Builder certification. Which is exactly what I did. One of the things that stuck out to me though, was ‘what is the difference between Process Builder and Workflow’?

    Both tools have now been around for a while. Though a lot of admins still aren’t sure about the difference between the two. So in this post, we will look at the difference between the two and more importantly when you might choose one over the other.

    What is Process Builder and Workflows?

    So let’s start at the beginning… What exactly are Process Builder and Workflows? In short, they are two features within Salesforce which allow you to build process automation within the system.

    Process Builder versus Workflow, which should you use?  What is the difference between Process Builder and Workflow?
    Process automation, helps simplify the user experience

    Both, Process Builder and Workflows, are very similar in the fact they allow you to define criteria and then do ‘something’ automatically without the need to code. This is what is called Declarative Development, or in Salesforce speak ‘clicks-not-code’ may be something you may have heard.

    You may have a process requirement you can automate for your users. For example when an Opportunity is updated to ‘Closed Won’, you then need to create another record (like a Contract) and send a notification to the Fulfilment team. This type of process can easily be done using the process automation tools within Salesforce, with no coding skills required.

    This is one of Salesforce’s strengths in the CRM space. A large number of other CRMs out there, typically did not (and still don’t) allow any users within the system access to this type of process automation. Instead requiring custom development / coding to setup or buying additional expensive add-on packages.

    Salesforce Workflows Rules & Actions

    Salesforce Workflow Rules & Actions have been available in the system now for a long time. Dating back many, many years – they were even available in the system before I started using Salesforce (all the way back in 2011). Workflow rules on custom objects were released back in Winter ’06… That is over 12 years ago now!

    Workflows Rules allow you to define a set of criteria. And then you control when the rule might fire (eg when a record is created, or every time it is updated).

    Additionally when the rule fires, it can be set to complete a number of the following actions:

    • Field Updates
    • Email Alerts
    • Create Tasks
    • Send an Outbound Message

    As a result, most Admins can then automate business processes with simple clicks-not-code.

    Salesforce Workflows: A Workflow Rule and Action

    But there was still a ‘wall’. This would be the point that you would have to move over to Apex triggers and classes to continue automating more complex processes…

    Additionally, there was no easy way to follow the entire process within the system. If you had multiple workflows firing at different steps, there was no way to see these easily. Diagnosing issues in a process become very complex. And Process Builder was born!

    Salesforce Process Builder

    Process Builder, or Lightning Process Builder as it is now called, started life as a beta in the Winter ’15 release. And one of its main goals was to allow Admins to create the entire process in one place, rather than using multiple workflow rules.

    So the big ‘win’ here how you can connect different steps together to make a single process flow. And it is very visual.

    Also by creating a complete process, you can also control which step is executed when. This was an issue with Workflow Rules, you couldn’t specify the order in which a workflow rule would be processed. At least not without a lot of cumbersome customisation work (new fields, extra workflows, field updates, etc).

    Process Builder simply allows you to drag and drop your rule criteria. Meaning you can have more control over the order things are processed:

    Process Builder, drag and drop criteria to rearrange order

    Add into the mix, some of the more advanced features which Process Builder now allows Admins to do:

    • Create Records (not just task records)
    • Update fields on any related record
    • Post to Chatter
    • Invoke other processes
    • Launch a Flow
    • Submit a record for Approval
    • Call/invoke an Apex class

    This is where we start to see some of the key differences between Process Builder and Workflows.

    And you can start to see why Process Builder has been created. It continues to drive the ‘clicks-not-code’ philosophy further, and continues to bridge the gap between what Admins can do versus Salesforce Developers.

    So, what is the difference between Process Builder and Workflow?

    To give you a high level breakdown between the two, let’s compare them side-by-side:

    Difference between Process Builder and Workflow... Which should you use?
    Process Builder vs Workflows… Which should you use?

    Additional Consideration: Bulk Record Updates

    There are one additional thing to consider though, namely existing automation within your org. Especially around support when bulk inserting or updating records (eg when updating 30,000 records via Data Loader). The good news is that Process Builder was ‘bulkified‘ (as of Winter ’16). However there can be issues when the code may not be setup in a way which accounts for Process Builder. This is something that Workflows handle without much further consideration…

    Existing Triggers, Workflows, etc may need to be reviewed to ensure Process Builder will work nicely alongside. Here is a detailed breakdown from David Liu over at SFDC99. It is a guide to when to code versus when not too, but it is aimed at advanced admins/developers.

    Update: 23rd July – Bulkification for Process Builder 

    The way Process Builder manages bulk requests is a point worth considering before implementing Process Builder.  A bulk request can be from importing contacts into your CRM, or an integration which updates a number of records as part of its process.

    When designing your solution, you should also focus on scalability and overall robustness of the design.  What do I mean by scalability?  I am referring to the the ability of your solution to handle increased volumes of data in the future.

    This article from ShellBlack (refer Rule #4), dives into the topic of Bulkification and Process Builder further.  And advises on some of the points you should consider before choosing Process Builder vs Workflows.

    A further discussion point on the Trailblazer Community Idea also expands on this topic.

    Want to learn more?

    For a full breakdown of the automation tools within Salesforce, you can view the list in Salesforce Docs.

    And if you want some hands-on practise, around implementing an end-to-end solution, there is a Process Automation Specialist Superbadge on Trailhead. These Superbadges cover the relevant theory but also gives you a use case and business requirements that you then need to solve and create the correct solution.

    Alternatively, if you don’t feel like completing the Superbadge at this stage – you can always go direct to the Trailhead quick-start module on Process Builder.

     

    UPDATED 23rd July 2018: to expand on the issue of bulkification and Process Builder

  • Technical debt in a legacy org

    Does technical debt keep you up at night?

    The bogey-man that is technical debt can sneak up on you when you are least expecting.  It adds complexity and delays releases, and is something you always have to remain vigilant of.  But you can master it, and minimise its impact…

    What is ‘Technical Debt’?

    Let’s just jump straight on in and define the topic of today.  I sourced this from Wikipedia:

    Technical debt can be compared to monetary debt.  If technical debt is not repaid, it can accumulate ‘interest’, making it harder to implement changes later on. Unaddressed technical debt increases software entropy. Technical debt is not necessarily a bad thing, and sometimes (e.g., as a proof-of-concept) technical debt is required to move projects forward.

    Based on that definition, can you start to think of parts in your Salesforce which may cause issues when you try to release a new feature? Technical debt and a legacy org can easily go hand in hand.   But it doesn’t have to.  It does rely on proper governance to minimise the challenges presented and stop them from becoming unwieldy.

    A legacy org

    As my first post alluded to, I am currently working with a legacy Salesforce org.

    When I say legacy, I mean 10+ years on Salesforce!!  Now as you might imagine, this presents some unique challenges for the business especially as we try to drive growth across the business.

    What are some of the challenges?  Things like the custom fiscal year feature were enabled, for no reason, within the org.  In turn this blocked us from upgrading from Customisable Forecasts to the newer Collaborative Forecast module…  (FYI this did change in the Spring ’16 release)

    We also have countless workflows on certain objects.  These perform core functions for a number of our teams, but means it is a challenge to unpick these one by one.  Instead there was a plan B, by requesting Salesforce Support to increase our workflow limit.

    Help is at hand

    After doing a bit of searching I have just stumbled across this video. I strongly recommend watching this session, as it details how AON reduced technical debt within their Salesforce instance by setting up strong governance practices.  For me this is quite topical, and as a bonus it looks like it was from Dreamforce ’16, so quite a recent discussion!

    Now these issues can pop up in any org, it isn’t a problem exclusively for legacy orgs.

    The key really is to address the issues head on and address any deficit in your roadmap.  Then you need to ensure that there is governance in place to help maintain and prevent the org from returning to its former state.  And finally, this needs to be communicated, with all stakeholders onboard.

    P.S. I will take this opportunity to apologise as well.  This theme of technical debt is one that I dwell a bit over the coming weeks 🙂  My next post will look at some of the tools I have used to define and quantify where the debt is in your org…

Back to top button