Choose the Right Tool for the Job With J Steadman

Today on the Salesforce Admins Podcast, we’re joined by J Steadman, Senior Solution Engineer at Salesforce, to talk through flows, processes, and the easiest way to move things from workflows to Process Builder.

Join us as we talk about the tools in your toolbox and how to view them as different things for different jobs, getting technical about workflows, Process Builder, Flows, and more.

You should subscribe for the full episode, but here are a few takeaways from our conversation with J Steadman.

J’s winding path to becoming a Solution Engineer.

J is a Solution Engineer at Salesforce, but what exactly does that mean? “I help people who are not yet Salesforce customers become Salesforce customers by building out demos of our technology to their specific requirements,” J says. The way he got to where he is now is one of those classic accidental admin stories we hear so many times on the pod. He didn’t get his first sit-down office job until he was thirty, working the front desk for an organization that happened to use Salesforce. He soon found himself as an admin, and that lead to a career as a Salesforce consultant.

The next stop for J in his career path was as a product manager for an enterprise customer with about 2,000 licenses in a big, shared, multi-tennant org with thirteen business units. From there it was a matter of time until he came over to Salesforce, first as a Success Specialist and now in his current role as a Solution Engineer. “It’s really fun in that for our strategic retail accounts, we’ve got a longer deal cycle so it’s not turn and burn,” J says, “so I get to spend time with these customers, learn their use cases, and actually present them functional technology before they even implement anything.”

Why you need to transition from workflows to Process Builder.

Right now, J is focused on how to transition workflow rules to Process Builder. “We had somewhere around 80 workflow rules that were all active on the opportunity object,” he says, “and I was tasked with not only taking those and migrating them over to Process Builder but also to add a bunch of new logic and functionality.” The fact is that in today’s Salesforce environment, workflows are limited—it can’t do everything that Process Builder can do. For admins looking for fast and efficient automation, Process Builder is the answer, but that can put legacy admins in a difficult spot where they’re split between the new solution and their old automations in workflows.

The biggest challenge that J has identified is order of execution. If you have a dozen workflow rules all firing on the same criteria on an object, you aren’t able to control the order in which those rules fire. Between Process Builder and Flow, that order can become very important as we build new solutions because legacy workflow processes can start to get in the way. While you can do all kinds of things to make things work, “when I look at the kinds of orgs I work in and the kinds of orgs I want to work in, I prefer to minimize hacking where possible, especially if hacking is causing me to create any number of false fields at the database layer,” J says.

Why J’s first step is Google.

J is a thirteen-times certified Salesforce professional—he’s an Application Architect and a Systems Architect, “but even with that degree of knowledge of the platform, my very first step for every single project is Google,” he says. He wants to look at everything from Trailhead documentation to conversations on the Salesforce Community and Stack Overflow to see if there are answers out there, or other problems people are running into. That lets him go back to his boss and his team to point out any obvious gotchas that might force them to course-correct before they get in the weeds.

The next phase is actually planning—reviewing the requirements. “I call this ‘having the hood up,’” J says, “while you have the hood up you have the opportunity to make changes not only to the thing you’re immediately working on but to the stuff that’s near and dear around it as well.” This is where you can start to see if the process actually makes sense. That gives you an opportunity to see how to adjust things to fit in with Process Builder, or if there are redundant workflow rules in place that are just slowing things down. One thing that can help is rigorous naming conventions and documentation, which J breaks down.

Finding the right tool for the job.

A common situation that comes up is when you build a new shiny process and then suddenly another team swoops in with new requirements. Do you add to the process you’ve built to make it bigger, or do you try to run with two separate, overlapping processes? “For me, the answer is pretty straightforward: I run with one process,” J says. “For the majority of our customers, pretty much everyone can be well-covered by a single process.” For more complicated orgs there may need to be two processes, but one of them should be a sub-process called by your master process. This idea that you build something once and reuse it everywhere used to be only available to developers, so it’s been a huge gamechanger to have it available for declarative development.

We have so many different tools in our toolboxes, “the trick is knowing what’s a hammer and what’s a screwdriver and what’s pliers. If we look at everything in the toolbox and we see it as the same, that’s where the confusion comes in,” J says. “But if we start to understand what these things are intended to do, specifically, then it’s much easier to know what to grab and when to grab it.” J gets into the specific differences between workflow rules, Process Builder, approval processes, and Flow to explain which tool you reach for when.

Resources

• Trailhead:
  • Process Automation Specialist: Superbadge
  • Lightning Flow: Module
  • Leads & Opportunities for Lightning Experience: Module

Social

• Salesforce Admins: @SalesforceAdmns 
• J Steadman: @J__mdt
• Mike: @MikeGerholdt

Love our podcasts?

Subscribe today or review us on iTunes!