Keep your Automation Simple

I’ll start this off by saying I’m guilty of not always keeping it simple.  But, I strive for simplicity.  Just because you can build something in Salesforce 10 different ways, doesn’t mean all 10 of those ways are right.  The solutions we implement often have a great deal to do with the skills and budget your Org has available.  Back when I was a Solo Admin, I was very guilty of duct taping together solutions, because the alternative solution was to have nothing.  We didn’t have the budget to hire developers for all of our ideas.

The purpose of this post is to discuss how we can simplify our solutions to make them easier for us to comprehend and maintain.  We’re going to walk through this set of requirements our project champion gave us:

  1. On Closed Won Opportunities, Alert Accounting with an Email
  2. Automatically Create a new Project for our Account Manager to run.
  3. Update the Account Owner to be the Account Manager
  4. Alert the Account Manager of their new Project, with a link to take them straight to the project.

Let’s take a first pass at solving this…

kiss-option-1

This accomplishes everything that we were looking to do.  We can now send the project champion a note saying that it has been completed… right?  Hold on!

Looking at this solution from end-to-end, how easy is this going to be for me to maintain?  On the surface, it’s pretty basic, but would an outsider easily comprehend it?

Let’s take another pass at simplifying it…

kiss-option-1b

We were able to simplify our automation by putting the Email Alerts into the Process Builder and Flow.  This looks easier to maintain and understand than our first process.  I would be tempted to call it quits here, but I think we could simplify the process further.

So, let’s take one last pass at simplifying this…

kiss-option-2

I’m feeling pretty good about this now.  Everything is in one location, and I can see all of my automation around this scenario in one spot!  Personally, I would go with our third and final solution if I was going to implement this automation.  Don’t go crazy and (when possible) and have Workflow Rules, Process Builder, Flow, and APEX all working together for one piece of automation.

4 Easy Ways to Improve Your Org’s Lightning Experience Adoption

#1 Optimize the Home Page

Add a Rich Text Component to create your Home Page Links to key Reports, Dashboards, List Views, External Resources, and other items.  It is all about creating a streamlined process that is enjoyable to the End User.

rich-text-drag

I like to use Bold Text to break up the links into different sections.

richtext

Clean up the page, get rid of excess.  Think about what the User really wants to see when they login to Salesforce.  If Top Deals doesn’t really work well for your Business, then remove it from the Layout.  Drag in your a Report Chart or other components that makes sense for your End Users.

CleanUpHomePage.gif

#2 Utilize Default Tabs

This small trick is one of my favorite parts of Lightning Experience.  I’m now able to set what the default starting point for a page is.  This is fantastic, because going to an Order you’ll typically want to see Order Lines (if you use them).  For a Contact you might care to see the Details first.  With the ability to default the tabs, we’re able to adjust this on every layout!

default-tab

#3 Customize the Highlights Panel

You have the ability to put a few key fields on the top of your page.  By doing this, you can give the End User a constant spot to look at those key Status, Amount, and Owner fields.  Unfortunately we’re limited currently in the number of fields we can display, so be selective of what you do display.  I prefer to use Image Formulas up here to give a quick visual representation of the record, as opposed to plain text, when possible. These fields are managed with Compact Layouts.

highlightpanel

#4 Get Creative with the Layouts

You’re not married to a layout.  You can create your own Layout from one of the templates available.  This ability to control not just the fields, but the whole page’s layout without any code is really awesome, don’t hesitate to use this feature.  You do have to create a New Lightning Page from within Setup.  You can’t hit Edit Page on a record and create a new layout template that way.

newlayout

Tailoring your Wave Dashboards with the Layout Manager

One of the things that Wave has recently transitioned from having the Flex Designer as BETA and making it now the Standard Wave Dashboard Designer.  Now that it is out of BETA we have tons of new features available that really allow you to create some fantastic layouts tailored to different devices and screen resolutions.  The beauty of the Flex Designer (now called Wave Dashboard Designer), is that it would change the different charts, filters, and other pieces of your Dashboard based on the size of the monitor.  Note: there were previously other ways of doing this, but now Salesforce has made this extremely easy!

 

When you’re editing your Layout’s properties, you now have the option to control the amount of columns and their spacing.  This gives you more control than before when you’re trying to make a beautiful dashboard.

grid

Columns determines how many columns your Grid will have.  The more you have, the more control you have with your different dashboard elements.  I’ve yet to hear of any downsides for bumping it up to 50 columns (the max).

Cell Spacing is how much space is between the different cells or blocks on your grid.  You have the option of 0, 4, 8, and 12.

4

4

16

16.jpg

The Maximum Dashboard Width plays into our next section on the Layout editor, Device.  This is where we get to control what devices and monitors will work with this Layout.

device

Screen Width allows you to set ranges that this Layout will work for.  In this image, I’m creating this for really large screens only, and I’ve just set a minimum width for the layout.  For my Standard layout I used both the minimum and the maximum width values.  Note: these numbers are in pixels.

Orientation is whether or not you want to make the Layout only work for Landscape or Portrait orientations.  It defaults to all, but having the ability to dynamically change it also based on the device’s orientation is fantastic!

Platform allows you to determine if your Layout works for iOs, Android, or both.

How does it all tie together?

When you’re editing your Dashboard you’ll see your Layout dropdown to the left of the back and forward arrows.  You can see here that I’m able to create my own Layouts for one Dashboard.  This gives you full control now over how the Dashboard will look at multiple aspect ratios.

layout-manager

Let’s take a look at this in action.  Below, I’m presenting you two very different Dashboard Layouts inside the same Cases Dashboard!  The first screen shot is for Large Screen Users, and the screen shot is for iPad Pro Users.  Notice, I can now add a variety of charts and filters based on the specific layout without any heavy lifting!

Large Screen View

largescreen

iPad Pro View

ipad-pro-dashboard-view

Understanding how Two-Column Screens work in Visual Flow

When I saw the release notes for Winter ’17, I was very excited about the ability to have two-column screens inside of Visual Flow.  When I first published my release notes highlights, there wasn’t any documentation out on how this was going to work.  Salesforce just published the Developer Documentation around the Winter ’17 Preview, and now we can start see the features with more clarity.  So, let’s dive right into this new feature!

You can find the Developer Documentation here on this feature.

Pre-requisite: You must Enable Lightning Flow Runtime for Flows to be able to use this feature.  From Setup, enter Process Automation Settings in the Quick Find box, then select Process Automation Settings.  Select Enable Lightning Flow Runtime for Flows.  Save your changes.

How can you use the Two-Column Layout?

Through a URL Parameter into your Flow, just like you would the Record ID or another variable.  Take a look my post on How to write a URL for your Flow if you need a refresher here.  It is going to look like this:

/flow/flowName?flowLayout=twoColumn

If you’re dropping your Flow into the Lightning App Builder using a Flow Component, you can also control the Layout in that component.  Simply choose the Two-Column Layout in the Flow Component’s Layout selector.  This defaults to One-Column (as you would expect).

FlowComponentLayout.png

How does the Two-Column Layout work?

Very similar to the standard Page Layouts.  You can determine the order of the fields, and every field alternates from left to right.  Be warned, it can look somewhat funky when you have fields that are not all aligned.
one-column

two-column-order

Things to keep in mind…

The Layout is for ALL Screens in your Flow

Let me reiterate this.  When you select your Layout, this is for ALL Screens inside your Flow.  You simply can’t control the column layout at the Screen level.  Another thing to keep in mind, is you’re selecting the Layout when you’re using the Flow.  This is all done in the URL or in the individual Flow Lightning Component – not when you Save or Activate your Flow.

Only available with the new Lightning Skin

Your Flow can be viewed in both Single and Double Column layouts.  If you have a Flow exposed on a Visualforce Page, you will not be able to select Two-Column Layout (at this time).  Flow’s launched by Visualforce will not use the new Lightning Skin, and thus this feature is not available.

classicview.png

Tab-key Order not customizable

You’re unable to change user’s Tab-key Order in the Two-Column layout.  It is automatically set to Top-Down.  If you’re not quite sure what I mean, the Tab-key Order is something that you’ve see in every Section Properties in a Page Layout.  This is not a huge issue to me, but I think it could annoy your Power Users who use Tab-keys efficiently.

taborder.png

Responsiveness

The Two-Column layout doesn’t care what the size of the user’s screen is.  Which means it is not mobile responsive.  This is something you’re reminded of in the Lightning App Builder through a Help Bubble, but not when you’re using a URL parameter.  Make sure you keep that in mind when you’re deciding to go with a Two-Column Layout.

Responsiveness.png

Recap: The new feature of having Two-Column screens comes with some drawbacks.  We’re not able to control Screens separately inside one Flow.  Right now if you’ve got something that you want to be accessed through a URL button (and not a Visualforce Page housing the Flow), then this will be a great solution for you.  I am hopeful this is just the beginning and we’ll soon be able to customize this at the Screen level, but we’ll see with time if I’m being overly optimistic.

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

Creating Your First Package in Salesforce

A few weeks back I decided to create a Package.  I had thought about creating one for months, but never invested the time into it.  It was way easier than I thought it would be!  If you’ve created a Change Set before, then you’re ahead of the game.  This blog post will hopefully give those of you who haven’t created your own Package the confidence and encouragement to!  If you’ve developed something that could be beneficial to other Admins, consider packaging it up and sharing it with the Community!

salesforcepackage.png

What types of packages are available for us?

PackCompAttri

Unmanaged Package

This is what you’ll see many of those Salesforce Labs and other free AppExchange Apps use.  By being Unmanaged, it gives the installer (Admin) full control of everything they installed.  It functions as if the Admin built it themselves.

Managed Package

This is what you’ll see an ISV Partner use.  The red section is their magic sauce, and they don’t want you to touch it.  This also allows them to Upgrade their package periodically with new enhancements and features.

(for additional details, please see the Salesforce documentation)

Should you set a Namespace?

If you’re going with the Managed Package, you don’t have a choice.  Managed Packages require a Namespace.  If you’re creating an Unmanaged Package, it is up to you!  The benefit for using the Namespace would be that you won’t have to worry about anyone having conflicting API Names in their Org.  If you choose to go without using a Namespace, the benefit for the Admin is that it really functions exactly as if they built it themselves.

Before adding a Namespace

Namespace1

After adding a Namespace

Namespace.jpg

Namespace2

Creating your Package

Select New in the Packages section.

Hit New.jpg

 

  1. Pick your Package’s Name
  2. Make sure you put in a very good Description for your Package, so any Admin can quickly recognize what your Package is doing.  Don’t make another Admin’s life harder!
  3. Determine if you want to use a Configure Custom Link (Displays as a Configure link within Salesforce)
  4. Notify on Apex Error (enter the username of the person who should recieve an email if an exception occurs in Apex code that is not caught by the code)
  5. Decided if you want it to be Managed or Unmanaged

Creating Package

Add in your Components

This functions just like Building a Change Set.  Select New and then you’ll go through and choose the Component Type that you want to add to your Package.

AddComponents.jpg

AddComponents2.jpg

The dependencies will automatically populate for you.

 The dependencies will automatically populate for you..jpg

Name your Version

When you’re ready, Select the Upload Button.

This will allow you to now choose a Version Name, Version Number.  You can optionally add in Release Notes, Post Install Instructions, and a Description to be shown after installation.  While the last three areas are optional, think about the Admins that will use your App and make sure you’re not leaving them in the dark on setting up and maintaining your Package/App.

NamingVersion

You can optionally add Password protection to your package, require Features to be enabled, and Require Objects.  I am not covering this in detail, because Salesforce automatically detects the required pieces that are apart of your package.

Select Upload… and we’re all done!  Take a look at your Installation URL, you did it!  You can pass this URL to anyone that you want.  You could even look to get your Package added to the AppExchange!

Version1

If you ever want to remove your a Version from being available, just select the Deprecate button while clicked in on a Version.  This allows you to make sure nobody can download an older Version of your Package.

Recap: Creating a Package sounds crazier than it really is.  It is very simple to do and if you have an idea or solution that you think other Admins would benefit from, you can Package that up and share it with the Community!  It is important to remember to use Best Practices with your Packages, and to make sure your have clear and clean Documentation in your Package for the Admins that will use it.  Take the extra time to polish your solution.  That means plenty of Descriptions and hopefully some Post Install Instructions!

Five Best Practices for Building a Clean Visual Flow

We’ve all been there, where you’re learning to write your first Visual Flow.  The main thing we’re focused on is just making sure that it is functional.  That’s fine while you are in your Sandbox developing, but once you’ve got it working correctly you need to make sure your Flow follows these five best practices.

Elements are Organized

One of the top rules for writing code is using proper indentation.  David Liu (SFDC99) is known for his love (or OCD) of clean code.  Visual Flow’s equivalent to indentation is the alignment of the elements into a clean format.  Think of it like you’re having company over – you would make sure you cleaned your house up before they arrived.

Your Flow should be very easy for you to follow the Flow Elements from start to finish without having to strain your eyes.  Keeping it clean also lets your Flow be easier to make future updates to it.  You don’t have to take apart your Flow to make sure you didn’t miss anything on your update.  So, be sure you spend the extra minute or two to make sure your Flow is sharp looking!

Bad

Messy Flow

Good

Sharp Flow

Naming Convention

In the developer realm, camel Case is the standard.  In Flow, we’re stepping into the developer world without really having to write code.  It obviously isn’t required that you use camel Case as your naming convention, but it is important that you follow a consistent naming convention.  If you don’t, your Flow will be much harder to read.

camel.png

Variable Names

In addition to your naming conventions, you need to make sure your variable names make sense.  I have opened up way too many Flows that use variable names that are not clear. If someone has to do some detective work to figure out what your variable is doing, you need to rethink your variable naming.  Variable naming can often be hard to do correctly, because you have to summarize the function of the variable into a small concise variable.

DoCaseId — Don’tRecordId

Why? RecordId is very generic and does not tell me what Object it is referring to.  I would have to go find where the value was assigned to see the Object it is the Id for.  CaseId is clear and I don’t have to do any research to figure out what it is.

Fault Messages

When your Flow fails its important for everyone to be alerted.  If you’re a Solo Admin, then you can technically get away without using a Fault Message, because Salesforce’s Email Alert will go to you.  However, if you have more than one person developing in your Org, this is a requirement! By setting up a Fault Message, you can easily alert all of the Admins and Developers of the issue.

It is also important to use multiple Fault Messages inside your Flow.  You’re able to customize the Email being sent out to provide specific information that pertains to that particular part of your Flow.  This will help you as you troubleshoot your Flow.

Fault Message

 

Descriptions

Make sure you use Descriptions in your Visual Flow.  This goes along with having your Flow Elements all aligned and easy to read.  You want your Flow to be easily digestible.  It is important to not write blatantly obvious Descriptions, just to write them.  You want to make your Descriptions helpful.

Anytime you have to do something unique inside your Flow you should include a Description to explain what, and more importantly why.  An example would be when you use a Formula in your Flow.

Description.png

 

 

Recap: Think long term when you’re building your Flows (or anything).  Just like you want to create a good User Experience for your End Users, make sure you create a good one for the Admins & Developers that are maintaining the Org.  None of these best practices require a significant amount of time to follow, and the benefits of having a clean Flow will be worth the extra effort!  And if you’re still reading, make sure you check out my The 6 Most Common Visual Flow Errors to Avoid.

 

 

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

How to use a Loop inside a Loop (in Flow)

This past week I saw multiple comments about using a Loops, and one in particular around doing a Loop inside of another Loop.  It is a pretty rare thing that you’ll do with Flow, because of the limits that you’re going to be dealing with, it is very easy to hit a wall with this solution.  Your second Loop is very inefficient, and has to run for every record that is found in the first Loop (which means a Fast Lookup/Query).  This SOQL queries limitation has been improved, prior to writing this blog I thought the limit was 50, but it seems Salesforce recently improved that limitation to 100.

So, keep your limits in mind when you begin to architect a solution like this.  Sometimes it can’t simply be done safely with Flow and you need to move to Apex.

limitsflow

Note: I know that you can add a Formula Field that brings the AccountID to the Campaign Member, but this is a simple example that gets the main point across.

Business Case:

  • When we lose a Client and mark them as a Former Client we want to remove all of their Contacts from all of their Campaigns

Process Overview:

  1. Account Record Meets Criteria – Process Builder triggered (Pass inputs into Visual Flow)
  2. Flow Finds ALL Contacts Associated to Account
  3. Flow Finds ALL Campaign Memberships for ALL Contacts
  4. Flow Deletes ALL Campaign Memberships for ALL Contacts

 

Now, because I’ve already done a post on Fast Lookups and Loops, I am not going to really dive into the individual pieces of this Flow.  I am going to give an outline of what each Element is doing, but I will only be focusing on the areas that are key to understanding how you can use a Loop inside of a Loop.

First, we are going to start out our Flow by looking for ALL of the Contacts related to our Account.  All we need to do is pass in our Account ID into the Flow so that we have that as a Filter.

First Element.jpg

FastLookup1.jpg

Next, we need to now Loop between each of the Contacts that we have found with our Fast Lookup, so to do that we need to drag in our Loop.

Second Element.jpg

Loop1.jpg

Now, this gets us to our Second Fast Lookup, which is where the magic happens.  In here, we simply need to take a step back and think about what we are trying to filter.  In this case I am trying to find all of the Campaign Memberships associated to a particular Contact (so that I can add them to a collection and then eventually delete them).  So, in my Fast Lookup I should be using my Looped Variable to bring in the Contact’s ID.

Third Element.jpg

FL in Loop 0.jpg

FL in Loop 1.jpg

Just like that, we are dynamically filtering this Fast Lookup for each Contact that comes into our Loop!  Pretty simple, right?  All that is left for us now is to setup our next Loop and talk about what we are doing there.

For each Campaign Membership our Contact has, we will be sending them through our next Loop.

Fourth Element.jpg

CampaignMember.jpg

Next, we want to assign the Loop Variable to another SObject Variable, our first step in creating a SObject Collection Variable.

Fifth Element.jpg

Assignment1

Now, we want to assign the SObject Variable to our SObject Collection Variable.

Sixth Element

Assignment2

So we just completed our Loop for the Campaign Memberships!  Awesome!  But, what happens when that Looped Contact has no more Campaign Memberships for us to Loop through?  This is where I’ve seen many people mess up there Flows (including myself every once and a while!), because there is typically a lot going around.  You need to correctly map your second/inside Loop to your first/outside Loop!  This is where we then repeat the process for every Contact that we had in our first Fast Lookup.

Loop to Loop.jpg

Great!  Now, all that is left is for us to determine what happens at the end of our First Loop.  In this scenario we want are sending them to a Fast Delete to get removed in bulk!

Seventh Element

FastDelete.jpg

Great, we are all set!  All that is left for us is to build our Process Builder to launch this Flow.

RECAP:  Loops inside of Loops are powerful features that can let bend the limits of Flow.  These should be used sparingly when you know your inside Loop won’t be used in a high enough volume that you’ll hit a transaction limitation with your Flow.  If you’re getting not confident that you’re going to stay away from that limitation, you should consider building this in Apex instead.  As you could imagine with a scenario like the one above, if we had any Accounts with upwards of 100+ Contacts we would be in some trouble! Beware of the limits!

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.