“It’s a small change, we don’t need to test it” said many a CRM administrator. What could go wrong?
Maybe this ancient CRM proverb will make you rethink that idea:
Because the admin added a field to the opportunity form, the field count increased beyond the mobile field count limit,
Because the field count increased beyond the mobile field count limit the form script couldn’t find the “next appointment date” field on the opportunity,
Because the form script couldn’t update the “next appointment date” field, the workflow that creates the appointment didn’t run,
Because the workflow that creates the appointment didn’t run, the sales meeting didn’t synchronize to the sales rep’s calendar,
Because the sales meeting didn’t synchronize to the sales rep’s calendar, the sales rep missed the meeting,
Because the sales rep missed the meeting, she lost the sale,
For the want of a sale, the sales rep was fired,
And all for the want of a proper testing procedure on small configuration changes.
Many variations of this proverb have appeared over the years, such as one where an administrator removes an option from an option set that makes a business rule fail, leading to corporate bankruptcy, or a configurator adding a lookup field to the accout form without granting users security permission to the lookup entity making an approval process not run, causing a nuclear power plant reactor meltdown. Whichever variation you prefer, the lesson is the same:
- Small changes can have big consequences
- All changes, no matter how small, need to be properly tested before moving to production
- There is a correlation between complexity of form scripts and work flows and the amount of testing required for small changes. A form with very few automations will need minimal testing when making changes to it, a form with many complex dependent automations will require extensive testing of modifications.
Nicely said !!! May I share?
This is so true!!!
Just happened to me recently: I’ve upgraded a 3rd party solution (Dynamics-365-Workflow-Tools) to a current version on both test and production environment – of course without any testing. Next day I’ve noticed a lot of failed workflow sessions. There was a bug in a particular WF assembly step (Update child records) that other custom workflows were using. Of course it was not possible to downgrade the 3rd party solution, so I had to backup all corresponding workflows, delete them (OUCH!), remove the 3rd party solution, install the lower version that worked (now I tested it properly), and install the backup solution with my workflows.
Lesson learned: every little change MUST be tested first.
[…] mean that the complexity of the solution couldn’t be high. The CRM Tip Of The Day post “The story of the small change” perfectly illustrates the way in which individual configuration items built entirely via the […]