Winter ’16

  • 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

  • Is it time to move to Salesforce Lightning?

    Salesforce Winter ’18 has now been rolled out across all Salesforce instances.  As you have noticed, Salesforce Classic didn’t get many feature updates, and almost the entire release is Lightning Experience focused.  You might have noticed the trend over the last few releases – seemingly everything Salesforce has done has been labelled ‘Lightning’ or only available for the Lightning Experience…  So is it time to move to Salesforce Lightning?

    How did we get to this point?  It feels like only a little while ago, we were all talking about key missing features.  We will take a look at the history of Salesforce and how Lightning came to exist.  What features are now available to you in Lightning Experience?

    Stepping back in time…

    Back in 1999, things were different.  Let’s take a step back in time…

    To connect to the internet, if you were lucky enough to be able to get it, your computer had a modem which made really funny noises and it could take a minute or two for it to simply connect with your ISP.

    Nokia 3310
    Not an iPhone in sight… Even the 3310 wasn’t available in 1999!

    Mobile devices looked quite different.  There were no iPhones or Android’s.  Even the Nokia 3310 hadn’t been released… It was released in 2000!

    The world used Lycos, Hotbot or Yahoo to search… Google had only started in 1998 and not many people used it (or even knew what Google was!)

    Do you Yahoo…?

    But 1999 also revealed Salesforce to the world.  And over that time there has been a number of UI improvements but the core of Salesforce has always been the navigating via tabs.

    Old Salesforce User Interfaces: Pre-Lightning UI

    Salesforce: a brief history…

    The world has changed considerably since 1999.  And so much of it, for the better!

    Internet in many offices now is super-fast broadband, some would even say “Lightning fast” (#sorrynotsorry, I couldn’t help myself).

    Internet speeds on mobile are also significantly faster and now we take for granted the ability to use internet on our mobile devices (let alone being able to stream Netflix on a mobile device).

    As a result companies switched to a ‘mobile first’ approach to development, Salesforce included.  This resulted in spending a number of features that became exclusive to mobile devices.  And as the Salesforce1 app on mobile devices continued to evolve the desktop version started to really look dated.

    Some people even resorted to using the “One App” on desktops to gain access to these new features.  This was mainly to test app features, but none-the-less there were stark differences between desktop and mobile.

    And over the last few years we can even add into the mix devices like smart watches, which allow us to be even more connected to our work.

    Introducing Salesforce Lightning

    This is why Salesforce needed to evolve again..  Enter Salesforce Lightning Experience (otherwise referred to as LEX for short).

    Lightning Experience across all devices…

    It was designed as a way to unify the interface across all devices.  While also introducing a new wave of web technologies to the CRM for admins and developers to be able to leverage.

    Lightning Experience (LEX) promised a whole new interface and way to interact with Salesforce.  When launched it was features like kanban boards for sales to manage their pipelines, news highlights & account news, sales path and being able to put graphs on list views which caught the eye of most admins and developers.

    That isn’t even mentioning the new design framework and components which let you extend the functionality on pretty much any page.  Lightning Experience suddenly expanded the world of point and click admins!

    Lightning – started with a flash…

    As with any transition though, not everything was working as expected.   Lightning Experience was quite cumbersome and sluggish to use.  And so many features of what became Salesforce ‘Classic’ weren’t even available in the new user interface, as an example Forecasts wasn’t available at all.

    Since being introduced as part of the Winter ’16 release, Salesforce was aiming for feature parity with Salesforce Classic within 2 years.  Over that time there have also been a huge number of improvements made.  Which begs the question, is now the time to move to Salesforce Lightning?

    Salesforce has not only improved how Lightning loads, but improved how Lightning looks and also introduced a range of brand spanking new features to Salesforce platform and only available in Lightning (looking at you Salesforce Einstein).

    Salesforce Lightning versus Classic

    Over the last two years the list of missing features in Lightning has been thankfully shrinking.  As you can see from the Salesforce feature comparison, we are fast approaching the milestone of feature parity in Lightning Experience.

    Clearly Salesforce isn’t just looking at feature parity, with Lightning “exclusives” such as Dialer, Assistant, new dashboards (not with just three columns) and even new report graph types are being released only on Lightning.

    Move to Salesforce Lightning for features like Kanban
    Salesforce Kanban and list view graphs (Source: Salesforce)

    You can also forget about using Salesforce Einstein sales features if you haven’t migrated…

    Looking at the list, there are still some specific exceptions.  But not being able to migrate to Lightning Experience due to a missing feature is now mostly a thing of the past for organisations.

    Final verdict: Move to Salesforce Lightning

    Lightning Experience has come a very long way since it was first released, and is now ready for most organisations to make the switch.

    Standout features in Lightning Experience do grab the eye of users and admins alike.  This is quite beneficial as it can help drive user engagement and adoption.  And ultimately this can help make the change to Salesforce Lightning an easier process.

    But now is the time to start planning the upgrade to Lightning Experience.

    Remember though, you do have to plan carefully for it (which we will cover in the next post).

    Most organisations should now be able to start using Lightning without having to keep switching back to Classic.  Even if there is a feature still missing, the Lightning Experience roadmap shows the future product releases.  Check it out to see if your missing feature is about to be released.

    What do you think?  Share your thoughts below in the comments section.

  • Data migration tips to save you time!

    So we are almost ready to go.  In this data migration series, we have already looked at how to migrate data and some tools to help with the migration.  But now for the fun part, I want to share with you some data migration tips to help make your migration into Salesforce as smooth as possible.

    Let’s jump right on in, and please share any of your own tips in the comments section below.

     

    Data Migration Tip #1: External IDs & Upserts

    Let’s walk through a common scenario in a data migration…

    The Data Migration nightmare:

    Data Migration can be like a mirror maze
    Too many spreadsheets? Where to go next?

    You are about to migrate 12 different objects into Salesforce, everything from Accounts, Contacts and Tasks through to Opportunities, Cases and a number of custom objects you have created in your org.

    How do you create these records in Salesforce, and still have all related records end up linked together?

    Do you insert the first object (let’s say Accounts).  Because you need to link the Contacts to those Accounts, in the second file do you use Excel to create the link?  Do you take the import file from Dataloader, run a VLOOKUP in the Contacts file and then pull in the related Account IDs?  YUCK!  Now imagine having to repeat that process for all 12 objects…

    I have been there myself.  And when it is a very large migration it can become extremely difficult to track and manage all the spreadsheets.  Especially when you are working with live data, that is always changing and is never static.

    This scenario can be the nightmare of any data migration but it doesn’t need to be.  #NoMoreVLOOKUPS

     

    Salesforce External IDs:

    As you know, each Salesforce record is given a unique 15/18 character ID.  That is great, if you are only dealing with data in a single system or Salesforce org.

    But what happens when you are need to store the ID of a record, that is actually sourced from a system outside of your Salesforce?  For example an ID from an invoicing system like SAP or Oracle.

    Setting up an External ID

    This is where External IDs come into the picture.

    By configuring a field to be an External ID you can then use it to store the original reference/ID from the other system.  Additionally, you can also use it to prevent duplication within Salesforce by setting the External ID field to unique.

    It is this ‘uniqueness’ that helps us out when migrating bulk data into Salesforce.  As Salesforce will automatically index the External IDs, allowing you to use this as a reference when doing an Upsert within Dataloader.

     

    #NoMoreVLOOKUPS: Upserts with External IDs:

    Now let’s take a quick look at Upsert within Dataloader.  Upsert combines the ability to either Insert/Update records while using a single file.  However, using Upsert in Dataloader also gives you access to a few extra features.

    Apex Datalodaer: vital tool to help in a Salesforce Data Migration

     

    After you click Upsert and start going through the Import Wizard, you will get the ability to select either the Salesforce ID or an External ID (if available on the object).

    Additionally, for any relationship you have on the object, Dataloader will also prompt you to select the applicable ID fields which is also referenced in our import file.

    This is how you avoid using VLOOKUPs!  

    By populating an External ID, on each record you load into Salesforce you can then use this to get Salesforce to do the lookup for you.  Even if you don’t actually have an External ID from another system, you can create your own.  Just make sure it is unique for each record.

    I know this is a little confronting to start with.  It took me a little while to wrap my head around just how exactly to do this when I ran my first data migration.  However Upsert & External IDs can save you so much time, I strongly recommend you practice and learn how to use this ‘double act’ to your advantage 🙂

    There is of course more resources available on this topic.  Salesforce Help has an article which gives you a step by step process you can follow.  I also found a video series on YouTube by Doug Ayers, which really breaks this down over an informative video tutorial.

     

    Data Migration Tip #2: Update System Audit Fields (Salesforce’s ‘hidden’ trick)

    In Salesforce, every record has a number of system date fields which typically can’t be edited.  Fields like ‘Created Date’, ‘Created By’, ‘Last Modified Date’ and ‘Last Modified By’ are locked down (and for good reason!)

    data migration 'hidden' toolbox
    Just like Maxwell Smart, you too can have access to a hidden toolkit of goodies

    These are your standard audit fields and are very important when tracking a record’s history.  While planning a data migration, you might come to realise that you need to retain this information from the previous data source.  And that is where the permission ‘Update System Audit Fields’ comes into the story.

    Imagine a sales person’s activity report, which is displays only activities created in this quarter.  As such after a data migration is complete, you still want your users to run these reports.  So what can you do?!

    In the past, being able to edit these fields was part of what I called the ‘hidden Salesforce toolkit’.  You know the list of things that Salesforce can do, but they don’t really publicise? Like increasing the cheeky workflow limit here or there…  But all part of the Salesforce Support toolkit, but you had to ask for it to be enabled in your org first.  The problem was, you had to know them in the first place you could even ask, so that you could get it requested to be turned on!

    Winter ’16 Release & Update System Audit Fields

    In Winter ’16 Salesforce made a number of these ‘hidden’ features publicly available.  And with a few clicks you can now enable it easily for your data migration.

    There are a few considerations to look at before you enable the ability to update the System Audit Fields, so check them out here.

    And then head over to here, for instructions on how to setup and enable this feature in your org!

    The biggest point I will highlight about accessing these fields, is that they are only available on record creation via Dataloader.  Meaning you can’t insert a record and then try to update the created date on it separately.  If you did try to edit/update these fields after a record has been created you will get an error.

     

    Data Migration Tip #3: Automation Anchors

    Automation with Salesforce is fantastic.  Admins and Developers have access to a wide array of automation tools within most Salesforce orgs, including Process Builder, Triggers, Workflows, Sharing Rules.  But when you are migrating data, they can quickly become an anchor.

    Automation Anchors, can slow you down unnecessarily
    Automation Anchors, can slow you down unnecessarily

    What do I mean by that?  Do you know what automation will fire off based on the data work you are doing?  For example, is there a workflow that will send an email alert to another team, or even the customer directly?  Is this what you expect to happen, if so that is OK.  But you do need to make sure you know what any data you load or update into the system will do to the existing automated processes in your org.

    In addition, automation in Salesforce can end up adding extra time to any data insert, update or upserts.  Remember even deletion of records can fire off a trigger!  When you are moving or manipulating a bulk volume of records, this time can easily add up.  Complex sharing rules might really slow down an insert/update of records.  And depending on the volume of data you are working with, you of may end up hitting some of Salesforce processing limits.

    So before doing any data migration, test and make sure the automation you expect to work does.  Otherwise see if you can deactivate the workflow while you are doing the migration.

     

    Share your tips

    This is by no means a definitive list, and there is plenty more to come.  But in the meantime, please share your own experiences or tips in the comments section below!

    Happy migrating!

Back to top button