Generating a product catalogue from one canonical file

Published September 3, 2026

A CRM product catalogue is usually typed in once and then quietly drifts from whatever document is supposed to govern it. This one is generated, and the drift it replaced had been sitting there unnoticed. The catalogue is built by a script that parses the canonical pricing document and writes the products, the units and […]

In this series · Part 22 of 34

1Dynamics 365 CRM: API integration + change-control repo 2Dynamics 365 CRM: Last Contact Engagement tracking on Accounts 3Turning a sales-intelligence export into a clean CRM data model 4Dynamics 365 CRM: contacts inherit their company’s website, and emails timestamp by send time 5Your SEO health now lives as a dashboard inside the CRM 6Contact form duplicate detection now reads the request, not just the address 7Marketing list members now show engagement and account fit 8Campaign responses now create leads behind a confirmation step 9Three CRM automations passed their tests without running the code that had just changed 10A signature defect that three mailboxes agreed was not there 11Asking whether a partner is involved, instead of inferring it 12Choosing what runs the AI layer in the CRM sales process 13A read-only CRM endpoint for scoring outside the desktop 14Why a corrected email signature kept sending the old one 15Two local dependencies, and only one was obvious 16Filing a generated document to the record automatically 17The rehearsal that guards every process change had been failing silently 18An email step in the sales process can now be excused, not only sent 19A one to one email from a lead left the engagement record blank 20One meeting that served two process steps, recorded as two 21A setting that stored correctly, read back correctly, and was never in force 22Generating a product catalogue from one canonical file 23Three date fields that existed on every row, and had never once been written 24Unused, unreferenced, and still not safe to delete 25A measure that could not record early 26A sales automation that runs as itself, not as an administrator 27A stage change that was refused, and reported as a success 28An Email Validation Gate for Campaign Sends in the Authgnosis CRM 29Marketing List Membership and Campaign Frequency Caps in the Authgnosis CRM 30A Send Guardrail for Unsubscribe Links in the Authgnosis CRM 31Automated Bounce Handling for Campaign Email 32Nurturing Cadence Automation and an Email Send Gate in the Authgnosis CRM 33A Hard Stop on Calendar Invites from AI Agents in the CRM 34Bounced Campaign Email Now Updates the CRM on Its Own

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 catalogue is built by a script that parses the canonical pricing document and writes the products, the units and the price list from it. Nothing in the CRM restates a figure, so the two cannot be edited apart by hand.
The catalogue that already existed disagreed with that document in three ways: a rate the document explicitly supersedes, a recurring figure matching no published tier, and several products carrying no price at all. Nothing had noticed, because nothing was looking.
A verification script now compares the live catalogue against the document and runs in the daily close out. It shares only the parser with the build, so a build that wrote the wrong value still fails the check. It was made to fail on purpose before being trusted: a seeded change produced exactly the two expected failures and a non-zero exit, and the source file was restored and confirmed identical afterwards.
One rule was recorded too broadly, applying a minimum commitment to every tier rather than to the single engagement option that carries it. That mattered beyond the documentation, because product descriptions appear on quote lines, so the wrong version would have stated a commitment to a customer on engagements that do not have one.