Designing a process from scratch is already a task and a half for your Salesforce org, but re-engineering a process is even a bigger undertaking when the process has been in use for some time. Many considerations need to be paid towards how to begin re-engineering, how to maintain the design after the solution is built and deployed, and what tools are required to plan its design and execute all this. Recognizing that there are a lot of things to think about, here is a small compilation of ways to tackle some of these questions. These are things that Salesforce solution designers are thinking of when it comes to designing a process to replace another one that just doesn’t fit the bill anymore.
1. Prioritize for value and technical complexity
In my interactive webinar series on how to design a process like a pro, I talked about prioritizing parts of the process to re-engineer based on business values that ranged from revenue generation, to user productivity, to customer experience. While these are important drivers in deciding which parts of a process to re-engineer, the technical effort also needs to be considered because these are the details that give way to an estimate of work involved. Since time and effort are also factors in prioritizing, here are things that we, as a team, discuss, evaluate and estimate effort on, to help prioritize which part of a process to re-engineer.
- Consider the existing Salesforce objects involved and the possibility of needing to deprecate or change them to fit the new process.
- Review the relationships between Salesforce objects and the possible need to change them.
- Consider the number of records that may need to be transformed, and the possibility of leaving them to coexist in the system.
- Analyze the existing automation being used given that there is usually a mix of automated processes, flows, triggers, and such, that need to be deprecated, modified, or potentially cannot be changed immediately.
- Account for the existing security and access, and the possible need to change them.
2. Demo early, demo often
Much like “save early and save often”, proactively keep tabs on how a re-engineered process is received by users. Don’t wait until it cuts over and is live in production before surveying users how things are going with the newly re-engineered part of the process. A reveal day like this can go awry if you didn’t have a good sense of user acceptance. Since we practice Agile, we demonstrate functionality at the end of each sprint. With sprints being relatively short, users see new releases early and often, as we complete them. Each time we demonstrate functionality, users have an opportunity to point out issues and provide feedback as we walk through functionality. Being able to get feedback from users, on-demand gives us a chance to adjust the solution so that it meets user needs. We consider this to be a pre-emptive quality check before handing the sprint release over for UAT, which is yet another period for users to validate that the changes meet their goals before accepting it in production.
This is not to say we haven’t gone through system testing, sprint demos and UAT with customers, deployed to production, and still had to come back and make adjustments during the support period. We might make changes then or add new improvement ideas to the project backlog, since changes in business and with customers often happen quickly. This is just part of reacting to live situations, find the next best way to work faster, and get more done—practically living and breathing productivity, progress and satisfaction.
3. Traceability, a buzz killer, and absolutely necessary
Certainly, documenting the design of a solution delves deeper than what was talked about in my webinar series, so let’s cut to the chase. Traceability is a bit of a buzz killer. It’s like the heaping pile of clean laundry I haven’t folded and accounted for, but I know eventually, I have to clear it so I don’t buy more socks, impulsively. Traceability is exactly this. It’s a mission to reduce, reuse and recycle, so that you have less technical debt and conflicting processes clobbering each other. Plus, if you’re working in a team all the time like we are, adding traceability helps everyone keep up with changes, decisions, the general understanding of how the solution functions and which user story is fulfilled.
Now, how is the hard part. Currently, my team writes a short design document for each user story we’ve identified. Each design document has two important things for traceability:
- A list of pre-existing API names of each declarative and programmatic item that will be modified because we’re recycling it into something else, enhanced, and re-used.
- A list of objects that will be created, modified, and re-used.
These design documents are then related back to the user stories that we’ve released for each sprint. By the time the project is complete, every user story has at least one design document related to it pertaining to what we built and how it functions for users. To take it further, we can search our documents by the project, by the object, by the API name, almost any keyword, to find what we need months later. We can re-establish our understanding of the designed solution and continue with the next stages of transformation and optimization.
Design principles we like
Between my team of Salesforce Consultants and Developers, each group has a noticeably favorite approach in design principles that they use over and over again.
The developers favor complete user stories with clear acceptance criteria. Whenever these were not clear, they felt that they could not design something that would represent what users needed, ultimately lowering the value of the solution. As for the consultants, who concentrate in declarative work and business analysis, they favor the end-to-end flow of process carrying out the expected outcome. For me, my attention over the years have gravitated a lot towards data normalization, and security and access. Even though I am a process engineer at heart, well-designed data and security have proven to be a key factor to the success of re-engineering a process.
Bringing SDLC back!
Life is a lot different than it was. Salesforce has always been a DIY platform that made it easy for admins and developers to build on-demand. The last 2 years have seen a widespread trend on architecting solutions. Salesforce solution designers are pausing their thoughts to build on-demand because they are concerned about technical debt, extensive org administration and support, and just simply being able to scale for growth. Traditional practices of change management and quality assurance have also made their way back into the fold where solutions are deployed from a Developer Sandbox, to a Full Sandbox and then finally to the production org. I am very excited to see so many great software design principles are being echoed in the Salesforce community. A lot of care is being given to designing processes and solutions holistically in Salesforce. We plan to continue being a part of this movement.
How Aria Solutions Can Help
Are you designing a process and have questions about how to tackle it? Download our design template to start planning out a process solution.
Our team is also here to help! Contact us today if you’d like to continue the conversation.
Anne is the Salesforce Practice Manager at Aria Solutions. She took her 14 years of experience in building contact centers and evolved it into understanding how a business operates so that she could design and build business processes in Salesforce, equipped with automation and supporting data models. She enjoys helping the sales and service industry understand who their customers are, and how to engage them.
5 reasons why you shouldn't build your o...
Designing a process from scratch is alre...
As we’ve come to know that understandi...
Change is the only constant in the conta...