A stage change that was refused, and reported as a success

Microsoft Dynamics 365 CRM

Before rebuilding the lead process so that sales steps can only be recorded by completing a task, four assumptions about the platform had to be tested rather than believed. All four held. The tests themselves turned out to be the fragile part. One assumption is that the progress bar on a record can be made […]

In this series · Part 27 of 27

1Dynamics 365 CRM: API integration + change-control repo2Dynamics 365 CRM: Last Contact Engagement tracking on Accounts3Turning a sales-intelligence export into a clean CRM data model4Dynamics 365 CRM: contacts inherit their company’s website, and emails timestamp by send time5Your SEO health now lives as a dashboard inside the CRM6Contact form duplicate detection now reads the request, not just the address7Marketing list members now show engagement and account fit8Campaign responses now create leads behind a confirmation step9Three CRM automations passed their tests without running the code that had just changed10A signature defect that three mailboxes agreed was not there11Why a corrected email signature kept sending the old one12A read-only CRM endpoint for scoring outside the desktop13Choosing what runs the AI layer in the CRM sales process14Asking whether a partner is involved, instead of inferring it15An email step in the sales process can now be excused, not only sent16The rehearsal that guards every process change had been failing silently17A one to one email from a lead left the engagement record blank18Two local dependencies, and only one was obvious19Filing a generated document to the record automatically20One meeting that served two process steps, recorded as two21A setting that stored correctly, read back correctly, and was never in force22Generating a product catalogue from one canonical file23Three date fields that existed on every row, and had never once been written24Unused, unreferenced, and still not safe to delete25A measure that could not record early26A sales automation that runs as itself, not as an administrator27A stage change that was refused, and reported as a success

On this page

Free Revenue Lifecycle Assessment

Connect with Marissa Wright to receive a free Revenue Lifecycle Assessment Report on your own business.

Book a consult →

Before rebuilding the lead process so that sales steps can only be recorded by completing a task, four assumptions about the platform had to be tested rather than believed. All four held. The tests themselves turned out to be the fragile part.

  • One assumption is that the progress bar on a record can be made read only, so that a step cannot be set by dragging it. A guard was attached, the move was refused, and the platform's own result code for that same move came back as a success. Both readings are true at once: the refusal worked, and the call that performed it reports that it did not. The stage was checked three times afterwards and had not moved, which is the only reason the contradiction was visible at all. Anything written against that result code would quietly record steps that never happened, so the rule taken from it is to read the state back rather than believe what the call returns. The guard was removed again the same evening, and the form confirmed byte for byte as identical to how it started.
  • The same question was then asked of every custom component in the system: is anything configured but unreachable? There is a quick way to check that from configuration data, and it was wrong three times in four. Three components it flagged work perfectly well when opened, including one sitting in plain view in the navigation menu, which is what proved the method unreliable rather than merely unlucky. One flag was real: a script written for this organisation is attached to a screen the application does not serve, so it has not been running. The check is now treated as a way of generating candidates, each confirmed by using the running system, and never as a verdict on its own.
  • Two of the four tests would have passed while proving nothing, and in both cases the fault was in how the test was set up rather than in what it measured. One was aimed at the wrong screen, chosen by reasoning that the right one would be the screen carrying this organisation's own script, which turned out to be the unreachable one above. The other checked that values copy across when a record is converted, using a record whose fields were empty, so a working copy and a copy that does nothing produce identical results. Neither would have announced itself. A test has to be able to fail before passing it means anything.

Other Posts