Optimizing Our Processes for Consistency and Reuse

This post is part of our “Lessons Learned from Salesforce Well-Architected” series.

One of the biggest benefits of the Salesforce platform is that it enables people to build process automations with little to no code. Tools like Flow can help organizations operate more efficiently without having to rely on developers or shadow IT automations built from spreadsheet macros. A potential pitfall with declarative automation tools is that they make it easy to skip the design phase completely and jump right into building automations without taking the time to think about whether you’re actually automating the right processes.

We’ll be covering process optimization in the Automated behavior overview in our Well-Architected framework when it’s released later this year. In this post, I’m going to share a story about how the Salesforce Architect Relations team optimized some of our own processes.

Background

Until recently, we had two different processes for publishing content. One was for our blog and the other was for our website. Aside from some document templates and a couple small automations to help push changes from our website staging environment into production, the steps in both processes were mostly manual. This was fine when we were a small, scrappy team that was just getting started and working with only a handful of authors. But as we started to grow and accept submissions from a variety of different sources, it became obvious that the manual work we were doing was never going to scale.

As a team of architects, our first instinct was to think about all the technical solutions we could implement to automate our processes. We came up with some pretty innovative ideas, but fortunately for us, we realized that before we started building anything, what we really needed to do was take a step back and look at our processes themselves. So we got the entire team together for a big, old-fashioned whiteboarding session.

Our approach

First, we sketched out both processes side-by-side. The process to publish content on our website looked like this on our whiteboard:

The process to publish content on our blog looked like this:

Once we had everything drawn up, we made some initial observations:

• Both processes have the same goal of publishing content. The main difference is just where the content is going to reside after it’s been published.
• Since the goals are the same, the processes have a lot of similar steps.
• It looks like we have some gaps where some of the steps in one process should also be in the other (and vice versa).
• Some of the process steps we listed went a little too far into the weeds; they detailed how we were actually doing things instead of just listing what needed to be done. This initially made it look like we needed two separate processes, but now we weren’t sure that we really did.

We realized that if we wanted to optimize our processes, we should think about some of our other Well-Architected behaviors as well, such as reusability. We decided that thinking of each individual process step as a modular component with its own set of properties would have a number of advantages over our previous approach, which was to think of each process as a monolith:

• Taking a more modular approach to our designs would give us the ability to make future modifications to any individual step, without creating any domino effects that negatively impact the rest of the process. This would help with long-term maintenance.
• Modularity and loose coupling of individual steps would also make it easier for us to reuse some of the steps in future processes.

Grouping steps to combine processes

Next, we began identifying the sets of steps in each process that we could combine into cohesive groups and categorize. We didn’t worry about the specific tools we were using to perform each step. We just focused on what each step needed to accomplish.

We started by circling process steps that we thought could be grouped together. We had some debate about what the groups should be and which steps belonged in which groups. Ultimately, we decided that listing the groups and using letters and numbers to identify the steps and order they should be executed in was a better approach. Now our whiteboard looked like this:

The end result

Once we had a clean list of groups and steps, we were able to sketch out a new process flow that combined the two previous ones. This is the process we decided to automate and it’s much more valuable to our team than the previous iterations:

• The process itself is reusable; it will work in a variety of different scenarios, regardless of what type of content we’re publishing and where we’re publishing it to.
• The individual steps are reusable; if we implement processes in the future that include steps similar to the steps in this process, we’ll be able to reuse what we already designed without having to do a lot of costly rework.

Had we gone down our initial path of trying to build something to automate our two separate processes as-is, we likely would have seen some incremental improvements. We would have eliminated some manual steps, but we still would have been stuck with two separate processes that essentially do the same thing but in an inconsistent way. Our improvements wouldn’t have been as impactful and we still would have had longer term maintenance and scalability issues. We also would have been adding technical debt by creating what essentially amounts to two duplicate automations.

Instead, this exercise helped us design a consistent, scalable process that will continue to save time and money as our publication needs evolve and expand. It also helped to reinforce in our own minds the value of following the Well-Architected behaviors we’re in the process of defining.