Apr 8 2015

I Wanna Flow Clone!

Brian and I talked about this on this week’s WizardNews WizardCast, but we thought perhaps a text-based walkthrough might be in order. So let’s talk about clones, baby.

The clone button on Salesforce records is great, for obvious reasons. But it has one major shortcoming: it brings over EVERYTHING.

Let’s say you want to clone a case, because a second client is having the exact same problem 3 months later. For one, it’s probably not going onto the same account, or have the same contact. For another, the Case Status probably needs to be reset to its earliest setting, since the original Case is (hopefully) closed.

But keep in mind that a mature Case object may have many fields that are NOT on the page layout, but nonetheless important to maintain. You may have an Approval Status that keeps track of approval steps but is hidden to prevent modification. You may have date fields that log when certain events occurred, but again, are hidden for security. You may have checkboxes or other fields verified by validation rules to ensure changes go through proper channels, like API or Flow.

These are all data points that you would NOT want to be brought over in a clone, because they are probably not going to be accurate for your new Flow.

So how to clone while still ensuring that existing data doesn’t become bad data? Simple! Flow!

Flows can be fired off of buttons, just like cloning, so that makes it an excellent candidate, plus Flow has the ability to read existing records and create new ones. Let’s take a quick look at what needs to be done.

We’re going to assume, to start with, that we’re going to be passing in the ID of the case we are cloning. We only need to pass that one piece of data in, because we can get the rest later. Let’s make a new variable: varCaseID. Don’t forget to make its Input/Output Type “Input Only”, so it can receive that data. If you leave it as Private, it’ll never be able to receive data passed to it.

Now that the Flow has a place to store which Case we are cloning, let’s get the rest of our fields. Create a Record Lookup, and set the filter to look on the Case object for a record where the Id is equal to our new variable, varCaseID. This is all you need to define, because you’ll only ever get one record with that ID!

In the section below, you will need to manually define which fields should get brought over in the clone. Yes, this may get tedious if you have a lot of fields that need to come over. But I would highly advise confirming with your stakeholders which data is truly needed. You’ll find most of your fellow employees or executives only want the data they really need, and are happy to let the rest go. You will need to store each of these data points in its own variable, and those variables can remain set as Private, because the Lookup will go and get the data; it’s not the same as having data pushed to it.

For the sake of this example, let’s assume the Account and Contact are the same; this is a whole other can of worms that would practically take a whole other article to examine properly.

Now that you have your old data brought over, we can begin creating our clone. All we need to do is add a Record Create to the Flow, and set it to create a new Case. Then, in the fields below, you can assign all of your variables to the proper case fields, like so:

That’s it! Draw an arrow between from the Lookup to the Create, and click the Start icon (the green arrow circle in the top right) on your Record Lookup so the Flow knows where to begin. You can now save your Flow, and create your Clone button.

Once you’ve saved your Flow, close it to get to the Flow’s information screen. On this screen, you’ll see a URL; copy this to your clipboard, you’ll need it in a second.

Now on to the button itself. I prefer calling the button something else, to reduce confusion. Something like SmartClone, to let you and the users know that this button is smarter than the average Clone. Before actually defining the button itself, I suggest changing the Behavior to “Display in Existing Window without Sidebar or Header”. This will effectively replace the contents of the users’ open tab when they click the button.

Now the URL for the button. Paste the URL you saved from your Flow, and add the following:

?varCaseID={!Case.Id}&retURL=/{!Case.Id}

Here’s the breakdown.

The ? is important because it lets Salesforce know to expect settings to be set in the URL. Each element we pass is essentially something we are setting this URL to do.
varCaseID – This is the variable we created, remember? Putting this here tells Salesforce we need to send something to this variable when the flow is started.
{!Case.Id} – This is a merge field that turns into the Case ID itself. You can generate this via the merge field operators right above the URL window, as always.
& – We can pass more than one piece of information, but we need to separate each one with a & symbol.
retURL – Here you can set where the Flow should go when it is done. If you do not set this, the Flow will just repeat over and over. By passing it / then the Case ID again, it knows to go back to the Case that started this.

It may help to put your varCaseID and your retURL on separate lines in the URL window. Adding line breaks won’t cause any problems, as they get ignored, and it makes your URL a lot more readable when you have to support/troubleshoot it later.

Voila! Put this on your case page layout, and you’ve got a SmartClone!

Jul 18 2014

The First Not-Really-Annual-We-Just-Do-This-When-We-Feel-Like-It Community Flow Hackathon!

On the 25th of June in the year of our lord 2014, it was hereby decreed that there would be a great ‘Thon of Hacking, dedicated to the communication of ideas and knowledge of The Great Flow. Over the following 7 days, many heroes from across the land ventured forth to slay the Dragon of Communal Ignorance, valiantly submitting their contributions and felling the great beast. When the dust cleared on the 2nd of July, there were only victors.

Hang on, I think my nerd is showing. Can you tell I run Dungeons & Dragons games in my spare time?

If you have any interest in Flow, I highly advise heading to the Success Community page for the #Sp14FlowHackathon topic, where you can see the collective hackathon in its entirety. It was started in the group “Official: Salesforce Workflow Automation“, and there truly were some amazing ideas. I’ll be dedicating an entire blog post to my submission next week, but at the moment I want to highlight some of the other submissions here.

(The following “awards” are mine and mine alone, and I do not represent Salesforce or any other company or individual.)

Best Use of New Features Award – Reassign Records when the Owner becomes Inactive

Jen Nelson brings the awesome with a Flow that uses Flow Triggers, Fast Lookups and Loops seamlessly. What’s more, it’s incredibly useful to ANY admin and operates quietly, predictably, and seamlessly. It’s the sort of automation that throws off new admins in the org; it’s so clean that it fools them into thinking it’s part of core Salesforce functionality, not realizing something else enabled it. Hey Jen, be sure you train any new admin you work with that this is flow! Otherwise he’s going to get that question wrong on his 201 Certification test!

Most Work Saved Award – Assign and Maintain Due Dates for all Tasks in a Campaign

Jen Dunn not only wins the award for Most Work Saved, but also for Most Patient Users! Whoever had the job of manually assigning and updating up to 35 tasks had a crap job, and Jen made it a whole lot easier! I just hope you didn’t put someone out of a job! This is a prime example of the power of Flow: taking a massive, repetitive task and reducing it to a few clicks. Bravo.

Wildest Idea Award – Clone Chatter Group with Members

Rakesh “The Flow Machine” Gupta makes us all ask ourselves the deep philosophical question: “Will I ever have to clone a Chatter Group? And if so, what am I going to do about all those Members?” That’s heavy, man. So hardcore. If nothing else, I love Flows like this because they make admins stop and say “Wait, Flow can do THAT? If it can do that, I wonder what else it’s capable of.” Nothing better illustrates the breadth of awesome that Flow can accomplish.

These are just some of the Flows that were shown. Go and take a look at the rest!

Jun 17 2014

Getting Record Type IDs in Flow without Hardcoding (UPDATED!)

Have you ever migrated your Salesforce data or fields into another org? Do you develop your new features in a Sandbox first? (And if not, WHY?)

If you answered “no” to both of these questions, ask yourself if you can safely say you will NEVER do so.

Chances are that any given admin will, at some point in their admin career, have to either migrate at least some part of your Salesforce, or at the very least be REQUIRED to build something complex in the Sandbox first, so as not to impact current process. If your company gets acquired, there’s a very good chance you’ll have to merge orgs. One way or another, you’re probably going to be beholden to this fact of life. The business world necessitates preparedness for just such an eventuality.

Previously, I had thought this would never be a problem. I’d never had to release anything that was so impactful that I couldn’t build in production and delay its effect (pardon me a moment while I slap my own wrists). I didn’t anticipate a full org merge with another Salesforce org, though I really should have. So I didn’t foresee the pain that would be, the horror known as: HARD-CODED RECORD TYPE IDs.

You may think that using hard-coded IDs is not a big deal, and if you only have one or two uses, it’s probably not. But over time, the practice can become pervasive in your admin methodology, and it will then grow well beyond those happy few. I mean, let’s face it, most of the time it’s a lot easier to deploy than other solutions, right? Just referencing a single ID is a lot simpler than writing the formulas, workarounds and methods needed to not use them, right?

The trick is, this trap has two kinds of cheese. The first is the fact that it’s usually easier, but the second is the fact that we as admins and developers often come to the conclusion that there is no workaround. Years ago this used to be the case, but today we have a lot more tools at our disposal, and many of the cases where we would be forced to use a hard-coded ID are not actually cases where we are truly forced, if we just keep working and digging at a solution.

Then I had an org merge to work. Because of our long-standing practices in our 5-year-old org, we had hundreds of single hard-coded IDs in our system. The trap had closed. In order to merge our system into theirs, we would have to reconcile ALL of those. We had a mountain of work ahead of us, because we had not looked ahead.

In working on solutions, I have developed a way to avoid hard-coded Record Type IDs in Visual Workflow. This has traditionally been a place which is widely considered to be inescapable for hard-coded IDs, but today I say thee NAY. There is a way!

(UPDATE: I had previously published a kludgey way of doing this, but it turns out there is a better way to do it that Salesforce has provided! Special thank you to MVP Aiden Martin for pointing out this exists!)

Create a Record Lookup, and when choosing what object you’re looking at, choose “RecordType“. Many an admin have glossed over that picklist choice, not even realizing it’s there, but this is an object usually referenced by Apex or API for the purposes of finding RecordType information. Because it’s in the API, we can use it in the Flow!

In your filters, choose “SobjectType” and set this to the object whose record type you are looking up. To determine which record type to use, I recommend using DeveloperName instead of just Name; the Name is the equivalent to the Record Type’s label, and is more likely to change. By basing it on the DeveloperName, you’re less likely to have issues with the name changing and breaking your flow.

Assign the Id value into a variable for use later and BOOM! You now have your Record Type ID stored in a variable for using later in your flow, and you didn’t have to manually enter it into the Flow. If the Record Type changes to a different ID in the future (and odds are it will), you will not be screwed. I REPEAT: you will NOT be screwed.

May 6 2014

How I Learned to Stop Worrying and Test My Flow

Do you write Flows? If so, congratulations, you’re a developer. No no, you are. You’re developing software, just with a declarative interface, so yes, you’re a developer. And what does every developer have to do, even though they hate it?

Test. Test. Test.

Once you’re a developer, you’re not exempt any more! Welcome to the development world. Yes, we hate testing. We like to think our Flow is just going to work the first time, but in all of the 30+ flows I have written in my time, I can only say that I am just lucky enough to have gotten away with it once. Seriously, that’s like a 3% chance.

Even then, I played it safe, and verified that it was going to work right by testing it first. You will save yourself SO much time and frustration by testing before deploying.

Flow is a unique beast, though, and there’s not a lot of documentation out there on how to test your stuff. By and large, we’re left wondering just what we should do to actually test. There’s some obvious things, but then the only truly obvious route is to actually deploy in order to test, and that’s not always a good option.

So without any further ado, here are some of the methods and guidelines I have come up with for testing my Flows.

1. Sandbox Sandbox Sandbox

I know sandboxes seem like a waste. I know the concept is alien to some of us. But really, do it. DO IT. This is especially important for Flow Triggers, which, I can attest to personally, can cause stupendous failures.

When a Visual Flow crashes, it only affects the person trying to run the flow, and usually just throws an error. When a Flow Trigger crashes, that crash can affect ANYONE who is trying to do their work. Even if you have “Administrators run the latest flow version” turned on, you can still have problems if you haven’t activated any versions. So trust me when I say, Sandboxes are more important than ever before for Flow.

2. Always Fault

There’s nothing that your users hate more than a cryptic error. Seeing

“An unhandled fault has occurred in this flow. An unhandled fault has occurred while processing the flow. Please contact your system administrator for more information.“

is the surest way to frustrate and confuse, not to mention driving your users AWAY from using your blood-sweat-and-tears Flow. Nobody wants to use a tool they don’t understand, so quite simply, they won’t.

So how do we avoid this? We add Faults.

Every Create, Update, Lookup, or Delete.

Any Record or Fast Element can have a Fault element attached to it, and your best practice is to ensure that every Record or Fast Element has a Fault element attached to it. A Fault element can be made by creating any element and drawing an arrow to it from your Record or Fast Element AFTER they already have an arrow pointing to another element. If the Flow errors on that source element, it will then perform whatever is in your Fault, rather than showing that “unhandled fault”. That’s what unhandled means; it means that you haven’t defined what should happen when a fault happens.

A fault can contain a message to the user, it can create records, it can even send an email if you use the Email Plugin. Anything Flow can do, you can make happen from a Fault, so this is invaluable not only to your users, but also to your debugging and testing. Having a screen that tells you what your variables’ values are AT the point of failure is essential.

Another quick tip: if you want your fault to do things AND present a screen (I almost always have mine send an email and then show a customized error in a screen), do the email or other things first, THEN do your screen. If a user gets an error message screen, they are a lot more likely to exit the screen instead of clicking the Next or Finish button, and if they don’t click that button, it WON’T fire your email or other actions.

3. Gotta Test ‘Em All

This is another drudgery chore, but as admins I cannot stress enough that you have to personally try out your functionality. Don’t just try your flow while logged in as you; try it while logged in as the actual users who will use it. Try each choice option you present in your screens, or at least a sample of them, if there are too many to test. Make sure you run your Flow through every possible decision path, to be sure each decision path actually works.

Also, try your flow while logged in as the actual users who will use it. What, I already said that? Well, good, it needs to be said again. It’s so easy to forget to do, because you have to do it in a sandbox in order to do it safely, but it’s one of the most important things you can possibly do in your testing.

So How Do I Test Exactly?

The Temporary Assign Element Method

The Run button is a great option in the Flow Designer, but unfortunately it’s fairly useless without some setup. Almost every flow needs some data passed to it, and that Run button cannot pass any of that data. So how do we make it useful again?

Create an Assign element BEFORE the start of your Flow, and in it, assign some sample data to the variables that would usually have been set. Draw its arrow going to the start of your Flow, and then make the Assign element the actual starting element.

You can now use the Run button with impunity! This makes testing a lot faster when you don’t have to click around to get to your Flow, and it has the additional bonus of being able to test your Flow (at least, the testing that you do while logged in as you) without making it live for everyone. It’s a great way to do quick proof-of-concept testing as well.

Please keep in mind this doesn’t work on any flow with sObject variables or collections at this time.

The Screen Debug Method

This ties in directly with bullet point 2 above. If, in your testing, you hit an error or bug or other unexpected result, being able to insert a temporary Screen that just repeats what the variables or Screen Choice values are at any given point can be the key to unlocking the mystery behind your dysfunctional flow. There is no reason this cannot be done at any time; you can insert this into the middle of your flow’s track without having to use a FAULT path, so you’re seeing things as they happen, even before the error comes down.

Of course, because this method uses Screens, it is incompatible with Flow Trigger flows. Bummer.

[Edit: Removed the Flow Debug object method. Turns out this has some pretty glaring issues with most faulting in Salesforce. Thus reiterates my overall point about being extremely thorough in your testing of, well, anything.]

Apr 24 2014

Video

Visual Workflow Live! Complete Task and Notify

After wrestling with YouTube, I FINALLY have this video up and ready. Needless to say, I have learned a few important things from my first live-streaming experience:

Do not play background music. Chances are it’s copyrighted, and YouTube will either restrict it or block it. Sorry, Salesforcers in Deutschland, this video won’t work for you. 😦 It also means the last few minutes of audio got muted forceably by YouTube, so I had to annotate it manually.
Do not check your own stream on the same computer you’re recording on. It’ll pick up and audio and you’ll have two audio streams being recorded simultaneously. It’s kind of like a time machine, thanks to the 20 second delay, but not as cool.
YouTube’s built-in video editor is OK. It works for what I need. Might need something more advanced someday, but for now, it’s good.
Need more people in the chat! Had at least one person in the chat contributing, and it was a big help. Thanks lifewithryan!

So without further ado, here’s the video from last week, and look forward to more video coming soon!

Apr 15 2014

Live broadcasting tonight!

Let’s try a little experiment, shall we?

Tonight, starting at 9pm Central Time, I’m going to be working on a redesign of a Visual Workflow for tasks to deploy to production. The twist? I’m going to be doing my work LIVE on the air for everyone to see!

I’ll be using a site called justin.tv, which is specifically designed for this sort of thing. Many different kinds of artists and designers use justin.tv to broadcast their creation process, and so I shall be doing the same.

I’ll be talking through my visual workflow work, as well as taking questions, so consider this a two-birds-one-stone kind of event; you can watch how visual workflow is made, and/or take the opportunity to ask an experienced Salesforce admin and visual workflow designer any questions you might have. The questions don’t even have to be visual workflow related! I’ll help out any way I can, if I can.

If you want to ask questions, you’ll have to create an account on justin.tv, but the good news is that accounts are free. If you get routed to a page asking if you want to pay for a Pro account for $9.99 a month, this is NOT NECESSARY, so don’t feel obligated.

When 9pm rolls around, click this link (http://justin.tv/salesforceyoda) OR the justin.tv logo at the top of this article, and it will take you there.

And now, a little FAQ:

What is justin.tv?

Well, have you heard of twitch.tv? If you have, justin.tv is the predecessor to twitch.tv, and is run by the same people. It’s basically the same thing as Twitch, but for things that are not games.

If you haven’t heard of Twitch, justin.tv is a live-streaming site. It lets people from around the world broadcast whatever they want (within moral guidelines of course) for free, for other people to watch. People can broadcast for free, and people can watch for free. And I mean free as in beer!

But the site is asking me for money…

Don’t worry about it. Click back and find the Sign In button at the top. I make no money from this, and in no other way get any reimbursement from Salesforce or justin.tv. Yes, justin.tv and Twitch have subscriber options where the broadcasters can make money, but I am not using that functionality.

If you’re not getting anything for doing this, why are you doing it?

Multiple reasons in this answer. One, I really like helping people, and having an “open office hours” of sorts appeals to me. I may not be the best admin, but I’m no slouch, if I may say so myself. This is my way of contributing.

Two, people love to watch people. It’s in our natures. And we love watching people do things that we do. I know that I would love to watch someone work in Salesforce; I looked to see if anyone was doing this sort of thing, because I wanted to see it! Since I couldn’t find anyone, I figured, why the hell not.

Three, visual workflow is a bit of a beast. It’s difficult to explain how you put a Flow together with text alone. By livestreaming it, people can watch and understand the process, and ask questions if they see something they don’t quite get.

How do I do (X) in Visual Workflow?

Woah there, Silver. Save your questions for the livestream.

How do I talk to you or ask questions once you’re streaming?

You’ll have to sign up for a justin.tv account, but once you do, you’ll be able to post in the Chat on the right side of the screen.

Why so late at night?

Believe me, trying to livestream with a toddler demanding your attention is not really possible. Trust me when I say it’s best to wait until after her bedtime.

If you’re doing your work live, doesn’t that put your company’s data at risk?

That’s why I’ll be working in a non-full sandbox. Cuz I’m smaahhht, see? Smaaahhht.

Ok, Mr. Smarty-Pants, what if we see you doing something dumb in the livestream?

Oh, I’m definitely human. I make mistakes. If you see me doing something in Salesforce that you think would be better done in another way, or is something that is just plain stupid, call it out! Let me know! I’m a big boy, I can take it. Even the best have their off moments, and I’m not even the best, so I expect my off-moment quotient to be higher.

Oct 17 2013

Know Your Flow: Post-Its for Beginners

So here’s the thing. I WAS going to write a short series of blog posts on How to Get Started on Visual Workflow. It was to be a Great Work, a definitive treatise bringing clarity, insight and edification to the lay user, its sole purpose being to exist in this world as an utter personification of knowledge.

Then I saw Keith Sadler had beaten me to it.

Check out his awesome Part 1 and Part 2 blog posts over at ButtonClickAdmin.com to learn how to use Flow and get started on your very own real-world very-useful sample Flow. I’ve had some conversations with Keith, and I know first-hand that he really knows his stuff.

I LOVE Post-It Notes. I don’t use them as much as I should, due to an overwhelming and logic-disregarding need to use as little paper as possible. I mean, come on, this is the future, right? The only thing we’re missing is flying cars. Paper is soooo 2nd Century BC. Even Evernote is trying to digitize them.

Post-It Notes serve many functions, but one of the most useful ones is to serve as not just task reminders, but as impromptu cubicle posters: tiny pastel-colored mantras that remind us not just to pick up the milk, but to think or act in certain ways. An inspirational poster with your favorite motivational quote will often cost upwards of $5-10, but writing it in pen on a Post-It and sticking it on the edge of your monitor costs pennies at most, with the added bonus of taking up less space!

Many such mantras are important for Salesforce Admins, or even for working people in general. I’m sure each of us knows at least one co-worker who would have benefited from having Wheaton’s Law permanently affixed to a prominent location in their workspace. And then there are the timeless admin Rules of Being Awesome put forth by Mike Gerholdt and the other MVPs; edicts like “Always build in the sandbox first”, or “Create trust in your data”, or “Communicate all changes!” These are, and shall ever be, key to success as an admin.

As such, I have come to call mantras like these “Post-Its”. They are friendly reminders on how best to work, and when it comes to Flow, there are certain “Post-Its” that one must remember as they begin their Flow journey. These are things that are not necessarily apparent, but crucial to keep in mind as you build your first Flows.

1. It’s Like a Flowchart, But It Does Stuff

Ok, you’ll probably have more branching than this. Doesn’t make it any less true.

If you ever have trouble wrapping your head around how exactly to build your Flow, the thing to remember is that it is, at its heart, a flowchart. If you’ve ever used Visio, OmniGraffle, Diagramly, or any of the myriad of programs that allow you to drop in shapes, write text, and draw arrows, you’ve done half of the work in Visual Workflow. The difference is, each of those Visio boxes can now be set up to DO something. ANYTHING. It’s extremely powerful!

Conversely, Flow works just like those charts do. It will only do things in the order in which you set them, and it will do things EXACTLY as you tell it to. Quite honestly, it is usually a great help to FIRST write out the flow you are thinking of, on paper or even in Visio, just to wrap your head around the logic, branching, assignments, and general order of things.

2. Screens Not Necessary (Mostly)

Almost every example or sample flow that you’ll see will have a Screen in it. And for the most part, great. Awesome. Communication is good. Generally speaking, you want to talk to your users as much as possible.

But what if you really don’t need to tell the user anything?

Notice there are no Screen objects here, except for the Fault error screen. We’re doing a lot here, but it’s all automation. There’s no need to tell the user “Job done” and make them click another Finish button when they already know what’s going to happen.

The thing to remember is that Visual Workflow has Workflow as its base. It can do nearly everything Workflow can, except that it has to fire off of a link or button. But in that sense, it can be treated like workflow.

Workflow doesn’t tell you when it’s completed successfully, does it? It just works. The same can apply to Visual Workflow as well. If you’re completing some simple automation with your link or button and you don’t need to obtain any additional information along the way,

Now I say this, but remember, my young Padawan, that only a Force.com Sith deals in absolutes. There are exceptions to every rule. Even if you don’t need to get any information or show a Finish screen, ALWAYS put in at least one Screen as an Error message/Fault. Generally speaking, each Record Create or Record Update should go to a Fault of some kind, even if they just share one.

3. Affect as Much as You Can

Flow is powerful, and frankly it can sometimes be easy to forget just how powerful it is. So you’ve finished that Flow that updates a Case from a custom object. Why stop there? You could update that Account field which tracks your overall Case status, make a Chatter post, send a Task to a manager to follow-up, and make a new Idea record, all with one click.

Obviously, you won’t necessarily want to go crazy with it. THE major hallmark of a solid project is a clearly-defined scope, and in any project your goal should be to stick to that scope. But thinking along these lines can help you to plan ahead of time, to (quite literally) go with the Flow. On more than one occasion, I’ve found myself listening to the request of a director or manager, and the more I think about all the different ways in which their department touches other departments, the more ways I find to connect the objects through synchronized cross-object data updates. Those connections create extra value in your system, leading to easier reporting and more complete data!

4. Install the Getting Started Pack (and filter out most of it)

On the AppExchange, you’ll find a hidden gem from Salesforce Labs called Visual Workflow Getting Started Pack. My advice: get this installed as soon as possible. Even once you do, you’ll have to sieve away a good amount of what is included to get to the gold nugget inside. That nugget is a little Apex plug-in that lets you send emails from Visual Workflow, an invaluable tool for communication in any organization that hasn’t fulled embraced Chatter or is trying to reduce Chatter clutter.

The one problem with this pack is all of the other things that come with it. There are a few other plugins that may or may not see any use, and a lot of sample plugins that, quite honestly, cease to be of any use after a certain point. Do yourself a favor and make a Flow view that filters out all the flows you no longer need.

5. Think Outside the Flow

I absolutely ADORE Flow like it was one of my children, but even the most loving parent should be aware of their loved one’s limitations. It is but one tool in the toolbox, and as powerful as it is, it’s no good at things like simple math or formula functions (e.g. LEFT, YEAR, SUBSTITUTE). You want to include the year of the created date in the name of your newly created record? Sorry chum. You want to create a Task, but you want that due date to be two weeks from the date the user specified in the Flow’s Screen questions? Good luck.

BUT there are ways of getting around those limitations. The key is to remember that Flow is but part of the Wide World of Salesforce, and it can interact with the other parts. Let’s look at the first problem: somehow parsing out just the year of the created date.

Set up a workflow that fires off when this type of record is created. Make it perform a Field Update that does the concatenation onto the record name, pulling whatever naming data you need. You can easily do the YEAR method on the CreatedDate as part of your Field Update; it’ll calculate it on the fly for you.
If a user creates the record manually, you can still have this apply. Just be sure to tell your users that the Name field will be filled in automatically, but because it’s a universally-required field (being a Name field core to all Salesforce objects), they’ll have to put something in before hitting Save. Anything will do. Hit the letter A and call it good. It’ll just get overwritten by your Workflow, as it should!
If you need it to only do this update on records created by the Flow, create a new checkbox field (not on any page layout, your users don’t need to be able to mess with this one!) called Generated by Flow. Have the Flow mark this as True when it runs, and edit the Workflow rule so that it only goes off when Generated by Flow is True.

See? We’ve combined Workflow and Flow seamlessly. Now let’s look at the other problem: adding days to a date specified during the Flow.

Get the date from the user in a Screen. Simple enough.
Immediately do a Record Update after the Screen, pushing the entered date into a new field. (Again, you can simply not put this on a page layout, if users don’t need to see it and you don’t want them tinkering with it after the fact.)
Here, you can go two different ways. You could A) make Workflow that created a Task and added the time as needed, or B) create a new formula field that simply does the addition of the days to that given date.
Make a Record Lookup to pull that formula field back into your flow, and make your Task as needed! (Remember that Tasks created with Flow can be assigned to a dynamically-determined user, rather than being stuck on a single name like Workflow does.)

Because Flow runs in order and doesn’t have to finish to do its work, your data can hop in and out of Flow! Anything that you can’t do in Flow, you can pass outside to the tools that CAN. Then pass it back and it’s like automagic!

The key in all of this is to make Flow work for you. The possibilities are nearly endless, and often it’s just a matter of figuring out the right path. Unless you’re talking about firing Flow without a button or link, don’t EVER let yourself think that something can’t be done in Flow!

P.S. Document and Communicate Like Your Life Depends On It!

OH one more thing! As a good admin, what should you do every time you release new functionality or replace old functionality? And when you release a new Flow, aren’t you usually releasing new functionality or replacing old?

The same thing applies here. ALWAYS document your new Flow, distribute that documentation to all relevant users, and do training/Q&A sessions to ensure that your users are properly able to use what you’ve given them. I’m not always the best at this, like a lot of admins, but I can tell you firsthand that the surest way to letting your users believe that you just sit and twiddle your thumbs all the ding-dong day is to not tell them what you HAVE done. Plus, you’ll alleviate the eventual head-hit-desk migraine and drive-to-drink, that you’ll undoubtedly encounter when you find that they’re using your carefully-crafted tool in entirely the wrong way.

Sep 20 2013

Admin’s Best Friend, Part 2

Aaaaaaaaaaaaaaaaaaaand we’re back.

In case you missed the last post, we are discussing the advantages of Visual Workflow, or Flow, over other Salesforce automation tools. Also, if you missed the last post, you can, y’know… scroll down. It’s still there. Oh no, don’t worry, I’ll wait.

Just in case your scroll wheel is broken, here’s a quick refresher? We covered that Flow can:

Create Records – One of the only bits of Salesforce automation that can create a record, and it can create more than one at a time too.
Perform If, Then, Else functionality, with Nesting – Branching logic that can make different things happen based on looking up data in Salesforce.

So now let’s move on to…

3. Work with Objects and Fields that Workflow Cannot

Ever wanted to do cross-object workflow from Case to Contact? How about workflow that creates an Event instead of a Task? Workflow that filters based on what department the User is in? Workflow that creates tasks with the owner being retrieved from a User lookup field? Workflow that makes a Chatter post? Workflow that refers to the Record Owner’s manager? Workflow that can do something as FREAKING SIMPLE as fill in a lookup field? (This is a personal point of frustration for yours truly.)

Welcome to the wild, winsome, wicked, and wonderful world of Flow.

Flow can access data from any point in Salesforce, provided you can give it a frame of reference. And it can create data anywhere as well. It can create any type of record, including some that aren’t quite obvious, like Chatter posts, Private Messages, Contact Roles, Case Team members, Opportunity Team members, Account Team members, Public Groups… The list goes on and on.

Within all of the objects available, you can create data and filter choices based on data you wouldn’t have been able to access otherwise. Not only can you access any data in the system to determine your actions (e.g. only creating a record if the Salesperson who clicked it is in a certain territory), but you can use it to access other data that workflow would normally be able to access, but just can’t. Have you ever tried to use workflow to populate the email of the $User’s manager for an approval process? I have. You can’t do it. Not without visual workflow.

: Nope, no Manager >> present. I had to make the Manager Email Address field!

4. Make a Single Click into a Workhorse Woolly Mammoth!

Each non-code automation tool in Salesforce has its strengths and weaknesses. Workflow can be chained to run one after another, but using it to move large amounts of data becomes cumbersome and unmanageable. Custom URLs can create records, though they can only do it once. But what if you wanted to do all of those things?

As far as I have found in my work, there is no upper limit on what can be done in Flow. I mean, I’m sure there is a limit SOMEWHERE, but I have yet to hit it, with my wild and woolly adventures therein.

As an example, let’s say you wanted to clone a record 5 times, bringing over 30 fields into the clone each time. Now let’s say it’s a DIFFERENT 30 fields in each clone. Sure, this is a pretty wacky hypothetical that generally falls beyond the realm of what one might ACTUALLY be asked to set up, but I have been asked to set up things that are not too far off. With workflow, you could have the fields populated when the records are created manually, but you’d have to set up 30+ field updates, one for each field that gets brought over. With a custom URL, you would need 5 separate URLs, as you could not create multiple records nor implement the branching.

skyrimmammoths

5. Automate / Drive / Force Process

To be fair, other kinds of button-click automation are also quite adept at providing this kind of service. But stop. Close your eyes. Think about driving process (or as Salesforce evangelist David Schach refers to it, “forcing function”), and think of all the things we just talked about.

Ok, yes, you can open your eyes if you need to go back and read what they were again.

Flow presents, by default, a Wizard-type interface. But what if it was your only method of making something happen?

What if you locked down your Opportunity’s Stage field and required the user to click a Flow button to make a change? You can filter it down different paths: if they’re changing the stage to Negotiation, you can ask and require certain information which then gets pushed into Opp fields, or if they’re changing it to Closed Won, you can require different information and even generate other records based on that, like tickets to setup your customer or other custom object records.
Do the same thing for Case Status, where if the owner is on your Retention team, you can require him to put in 3 dates for scheduled follow-up calls, and then create those Events for him!
Turn your User creation into a guided wizard process, to be sure that every step of the process is covered. (Because we Admins have a TON of things to think and worry about every day, and sometimes those little details just slip our minds, don’t they? Plus it can be a huge time-saver!)
Require that a date field be updated through a Flow (I’ll go into this in an upcoming post) so that the date field’s value can be copied into another record in another custom object. If these custom objects are not Master-Detail, you won’t be able to use regular Workflow for those!

When you can drive your Users to work down certain paths:

You minimize the demons of procrastination, obstinance, forgetfulness and human error.
You ensure a higher standard of work and customer interaction.
You ensure higher data quality.
You ensure quality metrics and analytics.
And you then become able to give your executive team whatever data they need without worrying about how reliable the data is.

Don’t think of it as being authoritarian or restrictive; think of it as ensuring job security for yourself.

Because when you become indispensable to your executives, they’ll do anything to keep you, and keep you happy! And Visual Workflow brought you there. I’d say that’s a tool worth learning, wouldn’t you?

Check it out! Joe Executive likes the cut of our jib! Eiffel Tower.

Sep 16 2013

Admin’s Best Friend, Part 1

Every admin has a favorite tool in Salesforce. Some live and die by the Data Loader, some have a passionate love affair with Workbench, and some have even made their own custom tools to make their Salesforce lives easier. But me… my best Salesforce friend is a little thing called Visual Workflow, or just Flow for short.

Now I know what some of you may be thinking. “Visualforce? That’s code right? I don’t do code.” Whoa whoa. Nay nay. Visual it may be, but Visualforce it is not. This is an entirely different beast, my friends. And while this beast may be intimidatingly big and hairy, it’s ridiculously helpful. It’s more like a workhorse, or pack animal. But big and hairy. So more like a woolly mammoth.

Look, the whole metaphor works if you just picture yourself as a caveman…

Image by David McCauley, “The Way Things Work”

Yeah okay, let me start from the beginning.

Most admins are in one of two camps: the camp that doesn’t know what Visual Workflow is, or the camp that thinks it’s too difficult for them to use. And to a degree, that’s ok! Nothing to be ashamed of. The reason most admins fall into one of these two groups is because Salesforce, unfortunately, has not done a lot to change things to the contrary. They simply have not talked very much about Flow, and the past few Release Notes have been practically devoid of any Flow-related changes to grab your attention. They’ve released a few videos trying to explain the whole Flow thing, but because of its complexity, those videos’ approach of “Let’s try to cover as much about Flow as possible in 20 minutes” only means that they don’t really allow for much in the way of detail or absorption.

But we can change this, people! Flow is the key to unlocking a new world of workflow in your system. It will allow you to do automation in Salesforce you never dreamed would be possible without code. It is the true enabler of the “Clicks Not Code” philosophy, the game changer for the next generation of Salesforce. And this is one of the key focal points that this blog will circle around: to provide a series of articles extolling the virtues of Flow and making it easier to start using it in your instance.

Alright, it’s teacher time. The first thing you need to know is what Flow can do. Some might say, “Hey wait, shouldn’t you focus on what Flow IS first?” Usually, I would say yes, but the key point here is that you know its worth. Flow can come across as complicated and having a high bar of entry, but if you’re aware of the crystallized AWESOME that it is capable of, you’re more likely to stick it out to the end. Trust me, it’s worth it. So what can it do that other tools cannot?

1. Create records

Ever wanted to automatically create a new account, case, or other kind of non-task record using Workflow? Can’t be done, can it? Record creation has long been the domain of APEX and custom-URL buttons. NOT ANYMORE, MY FRIENDS.

Visual Workflow gives you not just the power to edit records, but to create and delete them as well.

Want a button that creates 4 pre-determined records with one click? You can do that.
Want a button that removes one opportunity product and replaces it with another? You can do that.
Want a button that can clone an Opportunity but will only pull over specific fields? YOU CAN DO THAT.
And the advantage it has over custom URL buttons is the fact that it can do multiple records at once, even if they are in DIFFERENT OBJECTS. MIND… BLOWN.

IT’S LIKE A BUTTON THAT MAKES MUFFINS. Except it makes records. Which is just as awesome but actually more useful. Unless you have a medical condition that prohibits you from eating any food that is not a muffin. That would be useful, then.

2. If…Then…Else (with Nesting!)

Anyone with an coding experience will get what that is, but otherwise think of it like extremely advanced filtering for workflow. With regular Workflow, if you wished to do automation that could go down different branching paths based on different sets of criteria, you’d have to write multiple workflow rules, and you’d have a hell of a time trying to get multiples to interact with one another. If your filter criteria are in different objects, you’d just wash your hands of it.

But not so with Visual Workflow! Base your Opp workflow off of your Opportunity History! Create multiple branches that pass information down to the following automated actions, even if you keep branching and branching by more and more filters! Write automation that acts based on a combination of data in your records and questions asked of the user when they start the process!

This screenshot is but a sample from a live Flow running in our instance:

You don’t have to get as complex as this in your Flow, but it’s a relief to know that you have the ability if it’s needed!

That’ll do for today’s blog post! Later this week, I’ll publish Part 2, explaining two more awesome button-click-exclusive capabilities of Visual Workflow and what it means when we get all these horses lined up and ready to run.

The Swamps of Salesforce-Dagobah