It’s been a running joke between Tom and I that when a client or prospect says something is “Pretty Straightforward”, it almost never is. After mulling this over in my mind recently, I figured a blog was in order to share my thoughts as a business analyst and consultant on the topic, and hopefully help increase awareness of the hidden complexity that lies in any process.
Admins – this blog is for you! If you feel like something is straightforward, think about the rubric shared below. It is guaranteed to help round out your proposed solution.
Consultants – this blog is for you! If a customer says “It’s pretty straightforward” don’t believe them until you’ve consulted the rubric below!
I’ll make up an allegorical example for the purposes of this post, but hopefully it shines some light on this topic. Let’s say a customer or prospect says “I want to hire you to add a workflow rule to my org. It’s pretty straightforward, all you need to do is change the Account Type to “Customer” when they close a deal.”
Wow, it sounds simple. I bet you already architected the workflow rule in your head. When an Opportunity is modified and did not meet the previous criteria, update the related account type field to the Customer status. I bet you could jam that into the org in 15 minutes. Even 5 minutes! You’re going to be a hero!!! Wait, hold the phone….
This is the part where you need to check yourself. Let’s peel back the union and followup with these questions. This chart shares some points to check along with the reason why I would want to ask these questions. By no means does it contain every question, but hopefully this line of thinking helps you get clarification and avoid a deploycastrophe.
|Question||Reason for Asking|
|What business process has created this requirement?||Give me a chance to evaluate whether this solution is indeed the best way to help the client achieve the business process|
|Are there other workflow rules on the the Opportunity or Account Object?||Adding another rule may be unnecessary, instead modifying an existing one would be a more efficient way to handle this|
|What other business processes currently use the Account Type field?||Changing account type data could potentially harm other business processes if they are not considered|
|Are there currently any validation rules on Account?||Do the validation rules need to be modified to always allow this edit to be made by the workflow? If so - how can we test this?|
|What is your sandbox situation like right now?||Validate if the client is using sandboxes, are they up to date, and can they currently deploy with no issues?|
|How are you managing data backups?||If data is not being backed up, and you’re considering a rule that modifies data, how can you be assured you’ve got a good backup|
|Are there any triggers on Account?||If workflow rules are updating Account data and firing triggers, could that be an issue?|
|Is your org’s test coverage in good shape?||Can you even deploy a solution?|
|Any security considerations with the fields in question?||What if certain users had access to modify the account type field and others didn’t. Would this process break? Do we need to modify security as well to accomplish this task.|
|Does you need historic data updated?||I.e. if we’re changing the behavior of present edits, do all Opportunities need to be reviewed and update corresponding accounts|
|Are there currently any list views based on Account Type?||They will change if the context around the Account Type field changes|
|Are any of your users running reports or dashboards that use the account type field for criteria?||These will need to be considered for updating or retrain users on the new Account Type field|
|What type of documentation do you manage around your org?||Processes like this need to be assimilated into an org’s documentation so new users can get up to speed on what Salesforce does automatically for them|
|How can/would you like us to test this new functionality?||Testing to assure expected results can save a lot of heartache if things go awry (i.e. if there are other cascading workflows/integrations downstream). Understanding how this change will work in a complex environment assures success|
|Could more processes be added onto this in the future?||Give you another opportunity to consider the architecture of this logic/business rule and determine the scalability needs of the given solution|
The wrong answer in any of these situations could present you, the admin or consultant with a minefield to dance through or architect around. Or at least validate/test that there are not other related processes that will be negatively impacted.
So sure – that 15 minute fix now takes a day, but a day in advance vs. multiple support tickets from users with broken functionality is time well spent, and as a consultant we never want to have our customers go through that.
So remember, it’s not ever straightforward. Salesforce makes it easy to apply a technical solution, for sure. But no software application, ever, will be able to understand a business process and a stakeholders’ intent when looking to implement something new.
I hope this table is helpful as you’re evaluating features and functionality. It is but one small part of the mindset that we have at Red Argyle to a considered and reliable approach to delivering great work that makes our clients happy.