One meeting that served two process steps, recorded as two

Microsoft Dynamics 365 CRM

The sales process expects an awareness call and then a discovery call. On a smaller account both can happen in a single sitting, and the process had no way to record that. The lead stopped at a step the work had already satisfied. The satisfying logic already existed and nothing about the process changed. An […]

In this series · Part 20 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 →

The sales process expects an awareness call and then a discovery call. On a smaller account both can happen in a single sitting, and the process had no way to record that. The lead stopped at a step the work had already satisfied.

  • The satisfying logic already existed and nothing about the process changed. An appointment marked as the discovery booking ticks the booking step when it is created and the call step when it is closed, so one appointment covers both. The booking gate is never skipped. It is satisfied by a record standing for a meeting that genuinely happened.
  • A decline type was added to the task. Declining a step already means the work did not happen, and compression makes the same keystrokes also mean it happened elsewhere. Without a field to tell those apart, an automation reading the free text reason would create a record of a meeting that never took place.
  • The new automation writes no attendee of any kind, and refuses to act when there is no source meeting to compress into. It can record a real meeting and cannot invent one. That was verified on a record the automation itself created, not only on its design.
  • It deployed clean, switched on clean, and did nothing. A run whose condition is false still reports success, and a second fault killed every later run with a message that named no step. Both were found by reading the records rather than the run status.

Other Posts