The Salesforce Conversations [Part 3]

Agile, Flow, and a Filter

Welcome to the third episode of Tech Tales from Quarantine. This follow-up to "Adventures of a Salesforce Platform Expert" takes us into the realm of automation. As always, this is a work of fiction, except for the technology, that is very real.

“Meow”

Was I dreaming? I must have been – I always close my door at night to keep the cat out. Mind you, I have nothing against the cat. Well, not much... To be fair, I didn’t know I was allergic to them when we adopted her. 

I opened one eye.

“Meow”

She was sitting next to me on the bed, staring at me.

“How did you get in here?”

“MEOW” growled a deeper voice from the door.

I looked up to see my housemate grinning.

“Time to wake up – we need your sage advice.”

Sage advice? Now I knew I was in trouble. 

“I’ll be out in a minute. Please take the cat with you on the way out.”

Once they left, I quickly got dressed, sneezed, downed an allergy pill and a banana, and went into the living room to find my housemate and Angie discussing a client.

Angie was on the big screen – ever since the COVID-19 lockdown she had become a more or less permanent fixture there as we all worked from home. Of the three of us, she was without a doubt the strongest technically, especially when it came to architecture and process. She was speaking to my housemate.

“I think you’re right to consider Salesforce for this client. Security is critical and they don’t have time to build out the kind of complex security structure they’ll need otherwise. But I don’t see how that will solve your iteration challenge.”

“Iteration challenge?” I jumped in. “What’s the issue?”

“Perhaps you should start at the beginning,” Angie said.

My housemate began. “Okay, it’s a small company dealing with COVID-19 therapeutics and vaccines. They have to manage the development process, the trials, the distribution, the finances – everything. They have limited resources, and they are making things up as they go along. Things are moving so quickly they don’t have time for normal development processes.”

Angie jumped in. “I’ve been arguing that this is perfect for agile scrum – they can use simple stories and short sprints to do iterative development.”

“And I’m telling you that’s not fast enough,” my housemate responded. “Even if we did one-week sprints, by the time we worked with them to define a story and build it, the story will have changed. And we can’t just build configurability into the application because we can’t even get them to define what needs to be configurable – plus that adds complexity, and a documentation load that needs to be managed as well.”

“This is where you need a great product manager,” Angie argued. “They’ll bring some discipline to the process – it might take a little bit longer getting the client to agree on at least a direction of what they want and priorities, but that discipline will pay off in the long run.”

“But,” she added. “This may be a case where scrum isn’t the right choice. Kanban might work better, as it will allow higher priority items to be worked on as soon as resources are available.”

“I considered that,” my housemate replied. “It’s probably better, but I’m not certain it will be fast enough for their needs, and I’m concerned about resources – having a team of developers making frequent changes is expensive.”

He turned to me. “I know it’s a long shot, but you’ve pulled off some serious magic with Salesforce in the past and I’m hoping you have another miracle up your sleeve.”

“I mostly have cat hair up my sleeve this morning, no thanks to you, but let me see.”

They groaned as I stood on my chair and in my best wizardly voice chanted “Ne quid opus aliis”.

I stepped down and continued.

“Good software development process takes time. Bad software development process takes more time, even though it may not seem so at first. And the requirement here is that they need implementation in minutes and hours, not days. Building a software development process around that requirement is… well, we can do it in emergencies, but you can’t have a team in a constant state of emergency.”

I continued, “So there’s really only one solution: Don’t do software development.”

My housemate was staring at me blankly, as if I’d completely lost my mind. But Angie slapped her head with sudden realization. “You’re talking about automation!”

I nodded and continued. “You already know how easy it is to configure the Salesforce database.”

They nodded. “Salesforce also supports three types of automation. There’s workflow, which allows you to detect changes on an object and perform a number of different tasks such as updating fields or creating tasks.

Next there’s process builder – it has additional capabilities like calling into Apex code and updating multiple records, though it’s weak on performance and has become the less preferred approach.

Finally, there’s flow, which is essentially diagram-based process automation. It’s extremely powerful and can do many of the things software can do.”

Salesforce flow builder

“There are other more specialized automation tools as well,” I added. “Like approval processes where data changes have to be approved by defined individuals – something that would probably be very useful in your client’s business.”

I continued, “All of these types of automation are far more accessible and simpler than software development. I think your answer is for the client to train people or hire admins onto the teams that are defining their business processes so that they can build them and try them immediately as they make decisions.”

At this point Angie interrupted. “Wait, you’re not suggesting they build out those processes on live production systems, are you?”

“Oh no!” I answered quickly. "You create Sandboxes – copies of your live Salesforce organization – including Sandboxes that contain all of the data in the live org. You can build out the automation there and test it out before deploying them to production.”

“But how do you manage automation?” my housemate jumped in. “With software we have source control and development pipelines. It sounds like automation could lend itself to chaos.”

“And you’d be right,” I replied. “In fact, I've seen a lot of Salesforce installations that suffer from that problem. But you’re starting from scratch so you can build good automation management in right from the beginning. Use SFDX – the Salesforce development experience. It supports source control not just for code, but for all metadata – including automation, page layouts, reports, and even the database schema. It has a command-line interface that allows you to build out a development pipeline for all of those as well – so if you set them up with good process in the beginning, they’ll be able to iterate quickly across the team without losing the benefits of source control and modern development tools.”

Angie smiled, “You know, I’d looked at automation, but I was so focused on code that I didn’t really think of how you might combine the two. Use automation to allow clients to do extremely fast customization, and use code for cases where the longer-term use case can be defined, or performance is critical. I don’t suppose it’s possible for automation to make direct calls into code?”

I nodded, “both process builder and flow can call Apex code directly, so you have a lot of flexibility.”

My housemate was smiling. “I think the client is going to like this. It was definitely worth waking you up.”

“I’m glad you think so,” I said, “because you’re about to contribute to a new household expense.”

I did a quick screen share to the big screen. “So what do you say?” I turned to Angie. “Which of these air filters do you think will work best on cat hair?”

I could have sworn the cat started purring.

Thanks to Dan Appleman for his kind permission to publish this article.

Credits

• photo by Mila Sviderskaya