Why, Process Builder, Why! (Updated – Humble Pie Edition)


I published a blog post last Thursday and pushed it up to the Salesforce Community. I am a big fan of the community because there is always lively discussion and sometimes, like this time, Salesforce legends pop up! Shelly Erceg is way up yonder on the Salesforce org chart, so it is always fun and a bit nerve wracking when someone like that drops some knowledge on you!


BTW – Not the knowledge you want dropped on you!

Turns out, the documentation I had found was out of date and that in fact, there was no limitation…which means that the process builder was borking out from something I did (D’oh!).


After a quick trip to the corner for some weeping, it was back to the grind to figure out just what the heck was going on!

Well, here is the short version! I started with two actions and once that was working, I cloned the process and created the rest of the tasks (13 of them ) by hand! It turns out, that when I did that, I set the “Owner ID” on one of the tasks (number 9 to be exact!) to the case ID instead of case owner ID.

Now, I did do troubleshooting before I created the idea and subsequent blog post. In fact, this process has at this time 16 versions and I created at least half of those before I found the out of date article.

Bottom line is this…Process builder is NEW and most of us SFDC veterans will remember the teething pains that were felt when other new functions got rolled out. Heck, I remember S-Controls and the anguish that removing those caused! Process builder will get better and it is because of the dialog and openness that exists on the community and from people like Shelly!

BTW – I created a new category on my blog, “Humble Pie”, because I am sure this will happen again sometime!

Why Process builder, Why? (Humble Pie Update!)


*** Guess what? This blog post is OUT OF DATE – See this new one for the updated, humble pie, “it’s not salesforce, it’s me” edition! ****

Loads of fun today. I used the process builder to set up some really cool stuff that otherwise would have required a pretty big flow or some apex.

Basically, when a case of a certain type is created, X amount of tasks will be created as well. All was right with the world, created, activated and tested…and then…the world stopped spinning.

Workflow Action Failed to Trigger Flow
The record couldn’t be saved because it failed to trigger a flow.
A flow trigger failed to execute the flow with version ID blah blah blah.
Contact your administrator for help.Click to return to the previous page.

Huh, that is weird…maybe the email message would shed some light on this.

No help here

Move along, no help here

Sigh…Good thing I have a GIF of Batman doing a facepalm!


After a couple cycles of “deactivate, modify, activate, test”, and more fails with that uber helpful message, I dug into google.

There, on page 9 of the Process Builder Guide, I found the ONE dang line that helped:

“• You can add up to 10 immediate actions and 10 scheduled actions to a given criteria node.”

So, that was the root of this #whysfdcadminsdrink moment…but you know what? That is kind of crazy. I was able to save and activate a process that WOULD NOT WORK AT ALL! You would think that there would be some kind of warning or something, but if you did think that YOU WOULD BE WRONG!

So please, fellow admins, join me in voting up this idea, where process builder would actually not let you save it with a condition that would cause it to fail.


Lego, Salesforce and a den of Tigers!


I am privileged to be an assistant den leader for my local Boy Scout Pack (shout out, Mt. Baker Council!) . My son is a Tiger Cub in Den 2 and I recently gave a talk to the den around the topic of communications.

Tiger Cub!

Too Much Fun!

I volunteered to talk because I have a means of communicating ideas to the masses, which you are reading at this time.

It was a load of fun and I was able to hold their interest for an impressive (IMHO) amount of time even though my blog is just 1’s and 0’s instead of a printing press or antenna.

At the conclusion of my talk, I asked the cubs to pick my next topic. The topics were…interesting, but we finally nailed it down to Lego (Followed by Minecraft! Shocking Topics, I know!).

Honestly, it didn’t make me too sad to talk about Lego because really, there are a few things that I can distinctly identify as being huge influence’s on my life and career, and Lego is one of them.

I had quite a few Lego sets growing up, though nowhere near as much as my kiddos do. I can still remember a few of them, and will sometimes take a trip down memory lane (AKA, Ebay) and lament over selling them. I had some of the original space sets and I can still remember how proud I was when I completed the space shuttle set.

Oh man, how awesome was this set?

That scaffolding almost killed me!

But how can Lego’s be connected to Salesforce? Well, glad you asked! Here are some of the lessons I have learned:

  • To get from Point A to Point B, just follow instructions.
  • Always be (preparing to) improve(ing)
  • Have Fun!

Alright then, EVERYTHING looks AWESOME so let’s expand on this!

  • To get from Point A to Point B, just follow instructions.

READ the MANUAL! Salesforce has some CRAZY good instructions and guides that are accessible in a variety of ways. I have found that as long as you read the given guides you should be OK!

  • Always be (preparing to) improve(ing)

You will STICK (ha) to your requirements docs!

Things are going to change! I am one of those types that don’t get bothered by my Lego sets breaking. In fact, I am usually thinking about the next thing I can build while I am building. Everything breaks…even if you do manage to kraggle

your sets together, you cannot stop time…eventually the plastic breaks down.

  • Have Fun

I love working in Salesforce, don’t you?

Oh Yeah!

Ready for Casual Friday!

2 cents on Salesforce Process Builder


OK, maybe .25 cents worth!

I started playing around with Salesforce Process builder and I figured I would give the world my 2 cents on this new functionality!

The process builder is a HUGE step forward. It is really cool, especially considering this functionality is less than a year old. If you were amazed by what you can do with #ClicksNotCode before, this will be mind blowing.

3 things I like:

  • Up to 5 decision points. Raise your hands if you have ever had to dissect a HUGE workflow with multiple gnarly logic steps…OK, this one is for you all. Stop weeping, process builder is going to help tremendously. What I like is that you can have up to 5 conditions grouped under a process that run really as separate statements.
  • Run LOADS of Actions. There is NOTHING quite a fun has building out a super awesome workflow and then rebuilding the logic so you can run an approval process #sarcasm. One place for all this stuff now!

Only one not present Make me coffee

  • Great UI. I love Visio. Seriously, love it. The UI of process builder makes documentation a snap since you can just grab a screen shot and see in pictures what the heck is going on. You know what would make this better though? A Nice “Click here to Print” button that would print out the process along with all the “stuff” with it. Yes, I used “stuff” as a technical term.

3 things I don’t like:

  • Versions are a PAIN. To be fair, this is a beef I have with Flows as well. I should be able to deactivate, make changes and then reactivate. One of the MAGIC things with workflows is that you could make a change, save it, test it and be done. With Process Builder, you have to clone, enter a new name (WHY!), save then activate. If you find something goofy, guess what, same dang process. Much like flows, you very quickly generate a TON of versions.

Speak it Grumpy Cat!

  • Can’t edit an inactive version. Yep, this is another versioning thing. One of the things I particularly like about flows is that I can step into a previous version, make edits and save it. Of course, there is a warning that I cannot over write the previous version, I have to save it as a new flow or new version of the flow. Sometimes, if your versions are different enough, you have to dig in and see what you could have done differently.
  • Replacing Precision Tools. You could create a flow trigger stupid fast. You could do it from multiple screens and you could edit it after you have associated it with a workflow. Here is a corny analogy. Let’s say that you noticed you have a screw loose on a piece of furniture. To tighten the screw, you would go and grab the cool screw driver with multiple bits out of your tool box and tighten the screw. This is like using a flow trigger. Just the minimum to get the job done! If you were to do this same action the process builder way, you would grab the WHOLE toolbox which includes tape measures, hammers, pliers, pencils etc…and bring it back to the furniture. Sure, the toolbox contains the screw driver and you are accomplishing the goal, but you just don’t have to lug that toolbox around.

So, that is that. Let me reiterate again…I love process builder and I think it is a  fantastic piece of tech, but don’t take away the precision tools because the tool box is getting fancier!



My recent post on bypassing validation rules (WHAT CONDITION YOUR VALIDATION IS IN) generated a record number of comments. It is all kinds of awesome to know that folks are reading the blog AND asking questions. whos-awesome

Two comments in particular were around pushing the userID over to the flow. After much facepalming, I realized that I never really explained how to do that.


There are actually a couple of ways of pushing data to a flow, however, I am going to share with you all my absolute favorite ways of doing this that you can also apply to all sort of other situations. In true “SFDCinSEA” fashion we are going to take the well documented idea of a pushing data in a URL (Best write up EVER!) , applying that notion to flows (From the Source!) and throwing in a bit of a curve ball by doing all this from a formula field (Evil laugh goes here!).

To do this, you will need the following:

  1. A flow
  2. A flow variable for the running user (varUserId)…What was actually asked about in the comments
  3. A flow variable for the accountid (VarPassedAccountID)…Just because I can
  4. A Hyperlink field

The basic premise is that we are going to use the hyperlink to launch the flow. When the user clicks on the hyperlink, it will pass over the accountID and running UserId.

Enough build up…here is what it looks like:

“Hyperlink(“/flow/validation_rule?varUserID=”&$User.Id&”&varPassedAccountID=”&Id,”Validation Rule Update”)”

No title can ever do the utility of this justice!

Sorry, you will need to click on it to see it in all of its weird font glory

Hmmm, that was really anticlimatic..wish there was a way to kick that up a notch, but there really isn’t…this is just a good use of the tools salesforce gives us!

Here it is sitting there looking awesome on the layout.

Yeah, that is pretty!

just want to smoosh it’s cute little URL

And here is proof that the values are passing!

bypass part two


And yes, yes I am passing two values over to the flow.

Yes, yes I am

You can even use similar type of functionality if you decide to use a button.

One of the reasons I like doing this in a hyperlink field though is that I can change dynamically how this field is presented. For instance, I could use an image field to change how this looks based on some criteria. I could even “mask” the data by looking at the running user. Heck, I could even change which flow is actually running!

Enjoy, and keep the dialogue going!

What condition your validation is in


Validation rules and Decaf coffee are both things that can really mess up a morning.

what a crazy validation rule

one day, this will happen

Suppose you had a flow, and you were running said flow on an object that happened to have a validation rule right smack in the middle of the flow superhighway

The typical course of action is to write yet another exception to that validation rule based on profile, role, user, time of the day, etc..

Breaking the Rules

Breaking the Rules

The problem though is that if you create an exception to the validation to let your flow run, you have to let that exception go through the UI as well. Kind of like if your windows could only be opened all the way or closed tight…

Argh, if only there was a way around this…oh wait, the reason I am posting this is exactly because I do have a work around!


I prefer to think of it as Agile

I prefer to think of it as being Agile

We are going to do couple of tweeks to the flow and to the user record.

1) Add a new checkbox on the user record called “Ultra Awesome Validation Bypass”…or something like that.

Yeah totally just did that

Totally just happened


On the flow, we are going to add a couple things before the main updates…

1) Add a new element to the visual flow that does a look up on the user record

2) Add a new element to the visual flow that updates the field “Ultra Awesome Validation Bypass” to “TRUE”

3) Add a new element to the visual flow that updates the field “Ultra Awesome Validation Bypass” to “FALSE”


Start to Finish


Last Step (Pinky Promise!) is that we add in an exception to the workflow that if the “Ultra Awesome Validation Bypass” field for the running user is TRUE then the update is ignored.

We don't need your rules!

We don’t need your rules!


So, there ya have it. Now, like everything else, this is just meant to be a foundation for more and better and awesomer things. I personally really like this idea because it gives a flexible and situation driven method to bypassing validation rules.

Any questions or Comments? Send them on over! I love to hear from you all!