How to Optimize your Process Builder and Quick Action Speeds

Process Builder and Actions (Quick Actions) are two of my favorite declarative tools that Salesforce has.  I’ve had a few posts on Actions and how powerful they can be when you add in Process Builder and even sometimes Flow.  I’ve also specifically had a few posts on how to write your Process Builders so that you can optimize them for speed (read here).  Now, this idea on today’s post does go against the concept of having One Process Builder per Object, but I think it does pose a good argument against it.  That argument is SPEED!

I’ve seen scenarios where we want to use Actions to create record(s).  What if you want to create an Action that creates an Opportunity, which in affect you want to have the Opportunity Team dynamically updated, and maybe a few Tasks automatically assigned to the new Opportunity Owner?  This is all stuff that a simple Process on the Opportunity Object will run perfectly, right?  Yes.  However, that automation can bring your Action to a crawl.

The Influence

The inspiration for this post comes directly from some of my work in Apex.  I discovered what Future Methods were when writing some really fun code a while back.  In short, it just attempts to perform the action in the future, as opposed to during your current transaction (creating or updated a record).  This allows you to bypass some limits that you might have otherwise had.

The Solution

By moving our Actions from the Immediate Actions to Scheduled Actions and placing the Set Time to 0 Hours After [date field] to ensure that it fires almost instantly after the record creation or update.

Schedule 0 Hours.png

After setting the time, add in your Actions.

schedule0hours

Advantage

The real advantage here is speed.  By being able to delay certain actions from taking place in the transaction, you’re able to increase your save times.  The result is a faster experience for your End Users.  I don’t think I need to add anything to that 🙂

flash-2.png

Disadvantages & Considerations

I’m aware that the list of disadvantages for the one advantage might comes off like one of those drug commercials with 30 seconds full of side affects… but here we go 🙂

The biggest disadvantage to me is that the record(s) that you might be creating or updating won’t be “ready” instantly.  If the User using the Action is also the one whose expecting some of those Actions to happen automatically, then maybe it isn’t the best solution for them.

As I mentioned at the start of this post, this does go against the One Process Builder per Object design pattern.  If you have a scheduled action, you’re not able to do the “evaluate next” inside your Process.  That post, like this one, is not a mandate that you must follow.  As the Admin/Dev running your Org, you should be able to make an educated decision on what is best for your scenario.

The last consideration around implementing this is understanding its impact on testing.  It is much harder to test something that happens in the future.  This affects your manual testing and any Apex Test Classes.  I would be surprised if you didn’t have any scheduled actions in your Process Builders and Workflow Rules… so it isn’t like this type of action isn’t being used today by many of us.

Putting it all together

The goal of this post is to not say you must use delayed Process Builder actions.  It is simply to add one more tool to your tool belt for when you’re working with Process Builder and Flow.  These concepts are not one-size-fits-all… adjust the concepts to fit your Org.

How to add Quick Actions and a Link in Wave Analytics

If you’re using a Table inside your Dashboard or Lens, as you start to drill down into the data you probably want to either navigate to the record or perform an action. Currently, that is not something Wave is setup to do out-of-the-box.  While this is not a very hard thing to setup, it could be somewhat confusing for any Administrator that is trying to learn Wave.  By the end of this you’ll post you’ll hopefully have no issues adding the Open Record and Actions to your Dataset, and understand some of the quirks associated with the feature.

The first thing to note, is this is Dataset specific.  This change has to take place on every Dataset that you want the ability to drill into.

Before we get started, let’s see what we’re going to accomplish in this blog post:

Default

without

Quick Actions & Record Open Enabled

withactions

Navigate to your Dataset

We want to navigate to our Dataset by selecting Edit under the Dataset.

edit-dataset

Download the XMD JSON

You’ll see a blue download icon, hit that to download the file.

OpportunityDataset.png

Open & Reformat the JSON

When I open the XMD file in Sublime, you’ll notice it isn’t formatted in a readable way.  I would recommend getting a plugin that will reformat this for you.  If that isn’t an option for you, no big deal, I’ve found this site to be great at formatting and helping you troubleshoot errors.  After it is formatted, it should look something like this (if you’re working with a clean Dataset):

formattedjson

Understanding the Parameters

Great, so we’ve got the code formatted to work with now.  Let’s talk about what paremters we have available to work with:

  1. recordIdField
    • This is the field that enables your Actions and the Link to the record.
  2. Field
    • The name of the dimension that the menu appears on in dashboard and lens charts and tables.
      • Let me make sure it is clear — you can not add this to a Measure
    • This ideally is a unique value to enhance the end user experience.  If it is not, make sure you use the recordDisplayFields parameter to improve the user experience.
  3. recordDisplayFields
    • If you put your action and record open on a field that isn’t unique in your table, Salesforce will ask you to select the record that you want to work with.
  4. linkTemplate
    • The default for this is to the Record Id field (the row’s Id).  However, you can use this parameter to setup a custom URL that you send the User to.
  5. linkTooltip
    • This is used if you want the Record Open to have a hover message.
  6. sfdcActions
    • By default the Actions will be displayed as your Page Layout’s Actions.  If you want to modify the values in Wave, then you’ll want to customize this to create your own custom list.
  7. linkTemplateEnabled
    • Default is TRUE.  Set this to FALSE if you want to turn the Link off and only have the Actions.
  8. salesforceActionsEnabled
    • Default is TRUE.  Set this to FALSE if you want to turn the Actions off and only have the Link.

What it looks like together

finished-xmd

Update the XMD JSON

Now you just need to upload the updated JSON file into the Dataset, and then hit Update Dataset

UpdateXMDJson.png

Select Update Dataset

updatexmdjson2

All that is left for you to do now is run your Dataflow again so that our updates are put in place.  After your Dataflow finishes running, go in and validate that you now have the Record Link and Quick Actions working!  It looks like this:

withactions

I would recommend looking at this article if you want to do a deep dive into this.

How to use Case Comments with Communities in the Service Console Feed View & Salesforce1

This past week I had someone who is looking to use Case Comments in the Service Cloud, but wanted it to be listed as an Action in the Feed.  I thought it would be a good use case of many different tools within Salesforce being used together.  I am looking at possibly doing this with code and basing it off this post, but for now I figured that I’de show you how without code.  Let me be clear that if you’re not using a Community that you can simply use the Internal Comments field instead without having to do anything.  The only negative of going with this solution is that you’re not going to have your Case Comment Chatter Post visible until your Chatter feed is refreshed, but that is something that also happens with the Internal Comments field.  The Case Comment record is visible instantly.  And this works nicely with Salesforce1.  With that said, let’s jump right in!

Automation Overview:

  1. Inputs for Case Comment received (Action)
  2. Process Builder triggered (Pass inputs into Visual Flow)
  3. Case Comment created in Flow

For this solution we have two different options in how we can do it architecturally:

  1. Record Create – Create new Custom Object
  2. Record Create – Create new Task Record
  3. Record Update – Use Custom Fields on Account/Opportunity

For me, because of not wanting to further complicate the Task Object and not wanting to add excess fields to the Case Object, I’m going to go with option 1 and create a new Custom Object.

How will we build this?

  1. Create the Case Comment Extension Object
  2. Create our Visual Flow to create the Case Comment
  3. Create our Process Builder to launch the Visual Flow
  4. Create our Action on the Case

For this solution we have two different options in how we can do it architecturally:

  1. Record Create – Create new Custom Object
  2. Record Create – Create new Task Record
  3. Record Update – Use Custom Fields on Account/Opportunity

For me, because of not wanting to further complicate the Task Object and not wanting to add excess fields to the Case Object, I’m going to go with option 1 and create a new Custom Object.

What fields do we need create in this Custom Object?

  1. Auto Number
  2. Case (Master-Detail)
  3. Comment (Long Text Area)
  4. Public (Checkbox) Note: this only applies if you have a Customer Community.

CaseCommentExtensionObject

Let’s get our Flow created first since we can’t Activate the Process Builder without it  (Setup | Create | Workflows & Approvals | Flows).

NewFlow.jpg

The first step is going to be grabbing our Record Create.

RecordCreate1.jpg

We now need to create the variables we will use to create the Case Comment.

Case Id

CaseCommentParentIdVariable

IsPrimary (This is a BOOLEAN, not Text)

CaseCommentIsPublishedVariable

CommentBody

CaseCommentBodyVariable

Lets make sure everything is correctly mapped inside our Record Create.

CaseCommentCreation

Great!  So lets hit OK and set this as our Starting Element.

SetAsStartElementCaseComment

Now lets drag in our Record Delete.  This is so that we don’t add useless data into Salesforce.

RecordDeleteDrag

Create a variable for the Record Id of the Custom Object record we just created, when our Action is used.

var_CaseCommentExtensionId

Map it in our Record Delete.

DeleteCaseCommentExtension

Connect the elements together to finish our Flow.

FinishedFlow

And lastly we want to Save and then Activate our Flow!

SaveCaseCommentFlow

ActivateCaseCommentFlow

Fantastic!  Now we need to setup our Process Builder that fires this Flow.  So lets go create a new Process Builder for this.  (Setup | Create | Workflows & Approvals | Process Builder)

CaseCommentExtensionPBCreation

We want the Process Builder to fire on our Custom Object that we created, Case Comment Extension, and we want it to fire only when a record is created.

CaseCommentExtensionPB1

We don’t need to set any criteria here, but to be safe let’s just make sure that we have a Case ID and Comment before proceeding.

CaseCommentExtensionPB2

Now we need to map the variables in our Flow to the Values in the Custom Object, using the Type Reference.

CaseCommentExtensionPB3

Hit Save, then Activate your Process Builder. Now, lets navigate to go create our Action.

CaseCommentActionNewButton

Keep it on the default, Create a Record, and select Case Comment Extension (our Custom Object we created earlier).

CaseCommentAction1

Let’s make sure we turn off the Create Feed Item, so we don’t spam the Chatter Feed since the Case Comment itself will cause a Feed Item to be created.  Also, make sure we add in a nice Success Message and custom Icon to make the action look sharp!

CaseCommentAction2

Remove the Case Field and drag Public and Comment into the Action’s Page Layout.  Make sure you require the Comment field.

CaseCommentAction3

It will give you a small popup warning you about not having the Case field on the Layout, but you can ignore it and move on.

CaseCommentAction4

We now need to setup a Predefined Field Value for our Case field.

CaseCommentAction5

Set Case.Id to our custom Case field.

CaseCommentAction6

Now all that is left is for us to update our layout(s)!

CaseCommentActionToLayout

And with that, lets take a look at the finished product!

CaseCommentAction.png

Introduction to Salesforce Actions

Salesforce Actions are one of my favorite tools.  If you’ve got a group of Users that are heavily using Salesforce1, then you can really be a rockstar for them by understanding how to use Actions correctly.  But, Actions also work in Chatter Feeds, Quick Actions, and Lightning Experience!  While Buttons are not extinct, Actions are the future and you should look at using them!

salesforce_lightning.jpg

Global Actions

Where can these be used?  These can be used on any Record Detail Pages & Home Pages… so anywhere an Action can be.

Actions

Can be used on Record Detail Pages for the specified Object.  The biggest difference between a Global Action and an Action is an Action allows you to preform a Record Update.

Global Actions vs Actions

Global Actions allow you to build an Action that can be used across multiple objects!  This means, if you have a specific Record Create, Visualforce Page, or Custom Canvas that you want displayed in multiple spots (or maybe just on the Home Page), then this is your best option.  With the Global Action you are able to re-use your Action across multiple areas, which means it takes less effort to develop and is easier to maintain!

Quick Action (Classic) vs Salesforce1 & Lightning Experience

Ability to have different layout for Salesforce Classic compared to Salesforce1 & Lightning Experience.  When Salesforce added Lighnting Experience they did not group it into the Quick Actions layout, but instead added it to the Salesforce1 Action layout.  So, if you currently are using Lightning Experience, the layout (at this time) will have to be the same between desktop and mobile.  Down the road Salesforce might split this up into a new layout so that we can once again have different actions for the Desktop than our mobile devices.

Action layouts for each object are predefined by Salesforce, but you are easily able to override and drag-and-drop Actions around in the layout (just as you would a Field).  If you customize the Quick Actions (Classic) layout, but not the Salesforce1 & Lightning Experience layout, then the Salesforce1 layout will mirror the Quick Actions layout.

Actions Layout.jpg

Each Action has its own Layout (Works with Record Create, Record Update, and Log a Call)

One nice thing about Actions is how easy it is to drag-and-drop the fields that you want to be displayed for your Action.  Pretty powerful!  Combine with Predefined Values and you’ve got the ability to really streamline the experience!

Your Layout.jpg

Predefined Values (Works with Record Create, Record Update, and Log a Call)

With Actions, one of the biggest selling points is the ability to use Predefined Field Values.  This allows you to save your End Users time entering information (just as you would ‘pre-populate’ fields with a button URL hack).  You’re able to reference the Object that you’re on (if applicable), and the System Fields like the Running User and Custom Settings.  If you choose to display these values on the Action Layout, the End User can change the default value if needed.  If you don’t need the End User’s input, then simply remove it from the layout and the Predefined Field Value will do the rest.

Predefined Value.jpg

Action Design Considerations

Have you noticed that both Global Actions and Actions allow for you to select Log a Call as a type of Action?  All this really is doing is setting some predefined fields/layout changes for you, but it is still a Record Create of a Task.  The benefit, besides not having to set some of those predefined values, is that you get a beautiful Custom Icon!  When you are creating your Actions, be it a Visualforce Action or a simple Record Update, make sure that you’re using the Lightning Design System to use an appropriate Icon.  User Experience matters!
Lightning Design5

Lightning Design6

As of the Spring ’16 Release, we have the ability to now use Success Messages for our non-coded Actions (Record Create, Log a Call, and Record Update)!  This is something small (just like picking a Custom Icon), but it really does enhance your the User Experience of your Action.

Success Message 1

Success Message 2

Sometimes the Chatter Feed can get annoying if every little thing done shows up.  This issue  was also resolved with the Spring ’16 Release, giving us the ability to choose whether or not we want to Create Feed Item with our Action for any Record Create (includes Log a Call).

Create Feed Item

 

How to work with Related Records in Process Builder Criteria

When Process Builder first came out, the lack of error messages made it hard to adopt.  I have noticed from looking at the Salesforce Answers Community, confusion with Process Builder errors is a very common.  In this post, we will cover one of the most common mistakes for someone learning Process Builder – how to work with related records.

What do I mean by related records?

Anything that is referenced through a Lookup Field on an Object (including System fields like Created By).

lookupfield.jpgWhen you’re working inside Process builder, you’ll see a chevron next to any related object that you can navigate to.  This lets you then reference the fields of that Object in your Criteria and Actions.

RelatedRecords

This works like a charm, until you decide to have a Process Builder reference a Lookup Field that is not populated (so the value is null).

failed.jpg

Yikes!  We never want to see that error stopping an End User from saving a record!  What happened?  Salesforce will tell you in your Fault message (emailed), the variable “hasn’t been set or assigned.”  What does that really mean though?

You were trying to reference a related record, but your Lookup Field does not have a value or record in it.  This isn’t documented very well, and is an easy mistake almost everyone will make as they learn to use Process Builder.  This is a new problem for Admins, because we do not run into this issue with Formula Fields and Field Updates (in a Workflow Rule).  And, this is a serious problem because it actually can affect an End User’s ability to make a new record and/or edit an existing record.

So now that we know the problem, how do we fix it?

  1. Check for Null
  2. Formula Field

Checking for Null is the approach that I prefer to go with.  Either one can technically work, but I choose to keep my Objects as simple as possible and avoid adding excess fields.

For our example, lets say that we wanted to run some automation for our Opportunity when the Primary Campaign is Type = Trade Show.   We’d first need to make sure that our Opportunity actually has a Campaign associated to it, otherwise we’d get that failed to execute the flow error.  So, how do we do it?

Campaign ID >  the Related Record, ability to reference Campaign Fields.

Campaign ID  the Campaign Lookup Field on the Opportunity.

CampaignLookup.jpg

 

That means that the Campaign ID Field houses the value of the Lookup.  Which means we can check to see if there actually is a value!

SelectCampaignId

CheckforNull

Now, we are able to add the rest of our conditions that reference our related Campaign record.

Note – we must to check for Is Null BEFORE we reference the related record’s fields.  Salesforce checks our criteria from Top to Bottom.

typetradeshow.jpg

We can now reference fields on related records in Process Builder because we first validated that we had a related record.

Understanding how to write Process Builder Criteria

I am working on a mini-series related to understanding Bulkification (related to Process Builder and Visual Flow).   So, you’re going to see a theme of posts like this and Building your Process Builder for Optimum Performance and Bulkification where I focus on some design considerations with Process Builder and Flow.  The reason behind these posts are because Process Builder and Flow are extremely powerful tools that give those previously developer-only powers to the masses.  And as we all know… with great power comes great responsibility!  So, lets do our part to make sure that we build our Process Builders and Flows in a way that would not cause developers headaches.  I’ll cover the basics of the different types of criteria, and then go over why it matters that you take building criteria seriously.

spiderman1.jpg

When setting the criteria for our Process Builder to fire, our options are:

  1. Conditions are met
  2. Formula evaluates to true
  3. No criteria – just execute the actions!

Lets dive deeper into each of these and talk about when and why would use them, and some of the common mistakes that are made around these.

Conditions are met

criteriapb.jpg

Using this as our criteria gives us a few more options than what we used to have with Workflow Rules criteria.  Now, we have operators like Is changed and Is null that were previously unavailable to us.  Outside of those new options it is essentially just a cleaner UI.  Don’t forget about the ability to make your Value a Formula (see condition #3), you can use awesome functions like PRIORVALUE and grab in cool System things like your Custom Settings!  Speaking of, Jennifer Lee has a great post on using Custom Settings in Process Builder that is a must read for anyone not familiar with Custom Metadata or Custom Settings!

Conditions.jpg

So we can pretty much do pretty much everything inside this criteria option… but what are the pitfalls that we will run into?

Forgetting to check the Advanced checkbox.

I really wish that Salesforce didn’t hide this section, it needs to be front and center!  I feel like this is one of the biggest errors that people make when building a Process Builder.  It is often overlooked until you’ve got a Process Builder that is creating a record or sending an email, and you realize that you’ve just had six emails get sent out to a Client!criteriaadvanced.jpg

Using Is changed

While I absolutely LOVE this operator that Salesforce gave us within Process Builder, the fact of the matter is I have seen tons of Success Community questions where people get stuck on this.  It isn’t documented very well that Is changed will ONLY run on Updates.  This will not run on Create.  That means, you’re up a creek without a paddle if you’re trying to build your Process Builder to only fire when a value changes, but also have it work if that field has been filled out on create.  If anyone has a clever way that they’ve found to bypass this issue, I’de love to hear it.

Formula evaluates to true

criteriapb2.jpg

While not as simple as the conditions are met option, this gives us the ability to do everything that we would want to do.  The problem is that this often is more fragile than the rest.

API Field Name Changes

This option unfortunately will NOT update your formula if you have to change the field name.  Keep this in mind, because just about everywhere else in the UI this is something we’re accustomed to.  You will however be greeted with a lovely error message anytime you try to Clone ur Update your Process Builder

errormsg.jpg

Is changed for new records works!! kinda…

Here is a simple example of how you could use the formula evaluates to run on new records and still run ischanged on updates.

We essentially have separated our criteria into On record create and On any updates.

(ISNEW() && NOT(ISBLANK(field)) || ISCHANGED(field)

In my below example I only have to use ISNEW() because the Case Status is always filled out.

ischanged.jpg

No criteria – just execute the actions!

criteriapb3.jpg

This should not be used unless you have a very good reason.  Just because we have a simple action does a Record Update and nothing else does not mean that we want it to always fire on every edit.  This means that every single edit our Process Builder is firing.  How many situations can you think of that actually require a Process Builder to fire every single time?  Don’t be a lazy Admin and use this option just because you can!

Why does this matter?

Because of how Salesforce ‘bulkifies’ our Process Builders and Flow!

bulk.jpg

https://releasenotes.docs.salesforce.com/en-us/winter16/release-notes/rn_forcecom_process_bulkification.htm

The issue is that as we continue to customize an Object with more and more Process Builders and Flows you keep adding to the string length!  Remember that every simple Record Update in your Process Builder, no matter how simple, counts as an actual query that will be added into that ‘bucket’.  Previously with Workflow Rules you never had to worry about those simple Field Updates running on every edit of the record, but now as we try to keep our Process Builders and Flows bulkified it becomes an issue!

By fully understanding our Process Builder’s criteria (and using it correctly), we are able to cut back on the extraneous actions.  This results in two big things:

  1. Reduced process time when you hit Create or Edit a record
  2. You’re more bulkified due to a decreased the number of queries

Which means you’re now the hero of your Org!

hero.jpg

The “One Process Builder Per Object” Design Pattern

Ever since the Summer ’16 release notes dropped, the Salesforce Community has been going ecstatic over the one and only Process Builder improvement.  The Community is so excited with this one feature, that I have not seen anyone complain about Process Builder only had one improvement.  The reason is this improvement is a game changer in the Process Builder world, and it will change the way that we build our Process Builders.

ReleaseNotesImageEvalNextCriteria

Note: Evaluate the Next Criteria has one limitation currently.  It doesn’t work with Scheduled Actions (which makes sense).  So, if your Process Builder has a Criteria that includes Scheduled Actions, you’re out of luck for continuing any further down the Process Builder (and that particular Process won’t really apply to this Blog Post).  So keep in mind during this post that any Process Builder with a Schedule Action can’t be included.

Unable to do Scheduled Actions

One Process Builder to Rule them All!

TheOneRing.jpg

You’re probably asking yourself why would we want to build an extremely long Process Builder?  This idea comes from attempting to mirror the Apex Trigger best practice and design pattern.  Yes, there are additional benefits to this design pattern with Apex as opposed to Process Builder, but the main points still ring true.

#1 – Keep it Simple

No longer do you need to search through tons of Process Builders trying to understand what all is going on behind the scenes.  You’ve got all of your logic in one spot for you to look at (excluding Scheduled Actions).  Heck, Salesforce even mentioned how it makes it easier in the release notes!

release notes.jpg

#2 – Control Your Order of Execution

pemdas.jpg

So, just like with your Order of Operations, it is important to be able to know what order you execute Process Builder actions.  However, unlike the Order of Operations where we can follow a consistent process every time… with Process Builder we don’t know which order our Process Builders will execute in.  If we have 15 different Process Builders on the Cases Object, then we have no control over what order they will be executed.  It is quite scary when you realize you’ve got zero control over the order your Process Builders run in!

With executing multiple criteria in a single Process Builder we are now able to consolidate all of our Process Builders into just ONE.  And, in our one Process Builder we can drag and drop our actions around into the desired Order of Execution.

For a quick summary, creating one Process Builder to rule them all will allow you to simplify your Process Builders for each Object, and will allow you to have consistency in the way your actions are fired.  Do you have to do this?  No, there is nothing stopping you from continuing to build Process Builders in the same fashion that we previously did.  But, I would ask you to consider thinking about incorporating this design pattern into your Orgs once it becomes available.