Process Builder

Parsing Stuff with Flows (Part 2)

Standard

In part 1, I built out the change of thinking that we will need in this blog post to amp up our data parsing using flows. For a quick recap:

  1. The scenario is that we have questions and answers
  2. The flow does the parsing by treating questions as keys
  3. We are using a text input in a flow to simulate the action of a user copy / pasting question answers into a text field

As demonstrated in the last post, this works within the context of a flow, but now in this post, I am going to show you how to apply this. To demonstrate this, I am going to add a text box onto both the lead record and contact record to receive data, two text boxes that will receive the parsed answers and a checkbox to display an error state. To launch this flow I am going to use a process builder on the lead and contact.

New fields on the layout
Process Builder

The process builder functionality is the same on leads and contacts. The ID will be passed to a variable in your flow. This variable is used by the flow to determine which update action to use. The input is also passed over to a variable. This does mean that for those following along at home that they will need to change their formulas from using a text box to using the formula. This is in addition to the changes needed to make it an autolaunched flow (Removing screens, etc).

Now, I did mention the whole error checking thing in my last post, so baked that in as well. The key here is to first check for errors THEN figure out which record needs to be flagged.

The end result will be something like this:

with error check

So, how does this work? Fan-Tas-Tic. With just two processes and a flow, I am able to do parsing on each record.

end results

Adding this parsing logic to a new record would just be adding a new process and updating your flow. This is a great example of how you can use flows to harness the power of apex with the ease and lower support cost of configuration.

Now, this is setup for a pretty specific example…A rep would be pasting in data from an external source, but the methodology would be the same as long as you had a source of text. So, with tweeking you could use this on fun stuff like inbound emails or maybe even chatter posts!

How does it feel? Not quite like this, but close.

I have the power.gif

 

 

One flow to rule them all.

Standard
One ring

Photo taken somewhere in SFDC HQ.

Recently, I found myself in a situation where I had a specific thing (Top Secret, Sorry!) I wanted my flow to do, but across multiple types of objects. As I built out my flow, I kept thinking, how can I build this so that it is a smarter flow? One that can accept multiple starting points? Well, to quote the announcer voice, “We have the technology, we the ability…”

But, let’s scooby doo intro back to the start…here is what I know:

  • The functionality I wanted to build involves doing a similar action against a lead, account and opportunity.
  • I can use a workflow to kick off this change
  • I can use a flow trigger to kick off the flow

Let’s start with the flow. What I actually did is not as important and the method, so a neat screen shot is not needed! The key piece here is that I have an input /output variable named “VarPassedRecordID”. Beyond that, really the ONLY other piece of the puzzle is a couple of decision points, one for each record. The decisions are all looking at the prefix of “VarPassedRecordID”. If the prefix of the ID matches the criteria, then the routing goes to the designated action

Update Account.

Decisions with Actions

As a side note, I have started using this methodology in my criteria’s when I look for query results instead of looking for nulls.

The next step is the workflow’s. In my case, there are three workflows and each workflow kicks off a flow trigger. If you do not have flow triggers, go get them enabled! Flow triggers are great for these small jobs, though you could do this with the process builder as well…The flow triggers are themselves unremarkable. The only thing they are doing is passing the record ID over to the flows…wow, reading this one over, this is really boring functionality. Seriously, this is like trying to make a pair of needle nose pliers or a shop light sound exciting! However, like needle nose pliers or a good shop light, this is a very good piece of functionality to know about. You can add new object types in very easily and with out creating more and more flows.

Recap? Sure, why not, this blog post is seriously shorter than half my papers I wrote in High School…Size 12 font! Double Space! Times New Roman! Business, Business Numbers! Is it working?

tumblr_nm4d2wZ7Go1r7r8d2o1_500

  1. The workflow runs if the criteria is met
  2. The workflow kicks off a flow trigger, which passes over the record ID to the flow
  3. The flow analyzes that data, and based on the prefix, directs the data down the right path

The only real “gotcha” to be aware of is that if you are using custom object, the record ID’s might have different prefixes based on your environments. You will especially find this true if you are migrating up the custom objects.

 

As always, let me know if there are any questions, comments or suggestions!

 

Andrew

 

Automagically create tasks from templates in Salesforce!

Standard

If you are like me, everyday upon waking up, you are craving coffee. This craving requires action and also requires a set number of steps that will repeated as long as this craving is happening (Hopefully, forever and ever). If I were to map this out, it might look like this:Tasks to Coffee

The act of me waking up will prompt a series of tasks, and this is something that is repeatable EVERY TIME.

Now, apply this to your users. How often will the user be DOING something that requires them to CREATE a task or series of tasks? Here are a few examples I could think of:

  • After closing a deal, follow up tasks are scheduled for 30 / 60 / 90 days out
  • After contacting a lead, follow up tasks are scheduled
  • After losing a deal, create a set up follow up tasks

The key to this exercise is identifying ACTIONS that will require a set of tasks to be created. This is the challenge that I decided to take on with my Salesforce BFF visual flow and my Salesforce Frenemy Process Builder. The idea was that when a case meets a certain criteria, a series of tasks will be created…and is this wasn’t challenging enough, I decided to kick it up a notch and design the functionality in such a way that the tasks are not hard coded but actually templatized.

Here are the ingredients to this functionality:

  • “templitized” tasks
  • A flow
  • A process (though, you could use a flow trigger as well)

At a high level, what will happen is that the flow is kicked off via the process (or trigger). The flow does a query of all tasks and ONLY pulls those that meet our templatized criteria. These are then used as templates for the creation of new tasks. The example below is how I built this out so that a series of tasks are created when I mark a case as “Ready for Coffee”.

Enough talking! Release the Screen Shots!

Release the Screen Shots

Step 1 – Create a “templatized” task

In this case, I note that the task is a template by placing a flag on the subject and setting the task status to completed. By setting the status to completed, you can keep the task from staying open and visible on the users home page. In the example I am building out, I am looking for a subject that ends with “!MakeMeCoffee”.

Task Template XLS

I am using the connector for this because…well…it works and I didn’t want to do it by hand!

Step 2 – Create your flow

The basics of the flow is that there is a fast look up to find your templatized tasks and put them into a Sobject Collection. This collection is then looped through with your regular loop de loop, which builds out the set of tasks that will be created. Be sure to build out a formula for the subject field that strips away the template flags,

Build Task Subject

else, well, you might end up with a lot of stuff!

Flow Magic

As usual, when I built out my flow, I built out one version that is driven off of the UI (pictured below). This way, I can do rapid testing without activating anything. After things are 90% happy, I will remove UI elements and save it as a new flow.

Step 3 – Create your process

Process builder is my frenemy…I see the potential, but am still really sore over loosing flow triggers. But, the cool thing is that we have folks out there in the Upper Echelons of Salesforce looking at our comments and reading our blogs and they are making changes and I am excited for where process builder is going! Soapbox aside, I created a process for case and set the criteria.

Criteria Logic - Process Builder

The ONLY thing this process is doing is calling the flow and passing over just enough information to run. In the past when I have used flow triggers, I tended to push over more information, but since process builder requires activate / clone / activate cycle if something goes ker-plewy (for the record, I did this cycle 7(!) times for this demo!), I have switched over to just pushing over the minimum as a variable.

OK, so the work is done, you are all set…Let’s see how this works!

Now, for the proof.

I have my case created, and I am going to check the box that signals that I would like some coffee.Ready...

As you can see, tasks are now created associated with the case.Go!

To emphasize again, the power of the template is that if I (as a user, not a system admin) wanted to change something about the tasks are created, I can do so on my own and not have to wait for a system admin. Another great benefit for the admin / developer is that nothing is hard coded except for template criteria…and even that could be made more dynamic to handle further scenarios.

Further mind blowing awesomeness is that this is NOT just for tasks on cases…it could be anywhere…or even applied to other objects!

Questions / Comments / Buy me a coffee?

Andrew

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

Standard

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!

SNAP!

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!).

Doh

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!)

Standard

*** 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!

Batman-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.

https://success.salesforce.com/ideaView?id=08730000000DlNoAAK

2 cents on Salesforce Process Builder

Standard
Quarter

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.
pain

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!