I love Salesforce, but in my spare time I do a lot with gaming. I have a particular interest in the fighting game community (or FGC as it is referred to by its members). The FGC subculture is very competitive, but also very tight-knit, and this closeness, combined with time and creativity, has formed its own subcultural lingo, with terms like “salty” and “happy birthday”.

One of those terms is “tech”, which is short for “technology” but is often used more like the word “technique”. When someone comes up with “new tech”, it means they have devised a new trick, and if it’s useful, it’s likely to be seen and repeated by other players. Because of the social nature of the FGC, with tournaments being streamed live and higher internet speeds now making online matches a viable place for competition, new “tech” can often spread around the world and be used professionally within a matter of days.

Granted, not all new tech is actually useful.

In a lot of ways, the Salesforce community is similar. Admins and developers create “new tech” all the time, and with all of the online tools like the Answers community, the official Collaboration groups, and the blogosphere, the tech gets spread quickly from admin to admin, developer to developer. Just look at SteveMo’s posts; the amount of new tech he comes up with for reporting is insane! (The “Power of One” piece of tech is practically iconic!)

So last night I had a flash of inspiration for some new Visual Workflow tech, gave it a try, and met with some moderate success. It is dependent on Flow Triggers, so if you don’t have that pilot yet, this won’t apply to you, but that’s ok, because this tech isn’t quiiiiite usable yet by anyone. But we’ll get to that.

Here’s the concept: Let’s say you want to ensure that an opportunity cannot be Closed Won if it contains Product A BUT does NOT contain Product X. Previously, this was not possible without Apex, because validation rules do not run in that direction; you can control your Opportunity Products based on the Opp, but you cannot control your Opp based on the Opp Products. This is now possible, however, with flow triggers.

To start with, you’ll need to make a new checkbox field on your Opportunity. For this example, let’s call it Product Validation Alarm. Don’t put it on any page layout; you won’t need to actually access it. It just needs to be there, and it needs to be writeable by every profile. Once you have this, make a simple Opportunity validation rule that checks if Product Validation Alarm is TRUE. That’s it, nothing else needed!

Now that we have that to start with, let’s make our flow!

As a proof of concept, all that is needed here is a flow that sets that Product Validation Alarm checkbox to TRUE. If we were doing this for real, we would set up a Loop element with a Fast Lookup to parse through the OpportunityLineItems looking for any that match Product A, but for just the proof of concept, this is all we need.

A simple flow trigger can then be set up with any workflow rule. I created a rule that just looks for Stage to be changed to Closed Lost. In our scenario, you could have this go off when the Stage is changed to Closed Won, if you just want to set up the proverbial bouncer at the door of the club, or even when the Opportunity Product is created, if you REALLY wanted to be prohibitive.

Note that in the Flow Trigger we will have to pass in the opportunity’s ID to our Flow’s variable. (I LOVE that we can do this here instead of having to define arguments in the URL!)

Basically, what we are doing here is PURPOSEFULLY setting up criteria that will trigger a validation error. But we are using Flow to be the watchman that presses the Alarm button, rather than relying on a validation rule that cannot even fathom what might be happening. It’s like hiring a physicist to watch the Large Hadron Collider for anything that might go wrong, as opposed to hiring a 7th grade science teacher. (No offense to 6th grade science teachers, mine was completely awesome, super smart and one of my favorite teachers ever, but she probably wouldn’t have been able to be an overseer at CERN.)

Now, here’s the catch:

This is why I was saying that no one can really use this right now.

Right now, when Flow causes a Validation Rule error to fire, this is what it displays. It doesn’t actually show the validation rule’s error, and it doesn’t appear to be an option at all to display it.

This IS currently effective, however, at stopping users, even if it does not tell them why they are being stopped. It’s not good UX. If you’ve got reeeeaally savvy users, you can use this and give them a list of the flow IDs as they correspond to what is being blocked. Or, if you have only one of these errors, it’s relatively easy to train your users that when they see this message, it means they did {insert problem here} wrong. But even then… new hires come on, people forget because they don’t hit the error for months… it’s a minefield of possible problems.

So if you want to see Flow Triggers being able to be used as complex validation rules…

There is an idea on the Salesforce Success site requesting this very thing. Give it a thumbs-up to make sure this happens!

In the meantime, this still serves to show the sheer power of Flow and Flow Triggers. Go forth and use that power!