A hundred and seventy business units, and no diagram

A retail group selling through franchise partners had been running Salesforce Marketing Cloud for two years. It worked. Campaigns went out, consent was collected, welcome flows ran. What did not exist was any account of how.

The platform had grown one request at a time. Over a hundred and seventy business units had been provisioned, one per franchise partner, of which around thirty saw regular use and three carried nearly all the volume. The rest sat idle, because the partners they belonged to had neither the people nor the training to use them and asked the national marketing teams to send on their behalf instead.

Underneath, the customer record lived in Sales Cloud and the sending lived in Marketing Cloud, joined by a connector and a set of synchronised data extensions. Consent (the field that decides whether a given email is legal to send) was written from a public web page by a script, read back by an hourly job, and overwritten wholesale once a week. Every part of that was working as designed. No one could say what the design was.

The brief was not to fix it. It was to find out what it did.

We read the platform rather than interviewed it. Every automation, every journey, every query, every exclusion script and every CloudPage in the parent business unit, plus a shorter read of the two most active national units.

That produced the first real inventory. A hundred and twenty-six automations filtering franchise data, sorted into seven regional folders, most of them identical apart from a hard-coded record ID. Subscriber lists split into a separate data extension per city and per store (forty in one market, twenty-four in another), with bounce handling done by hand into numbered lists. A naming convention that had been formally defined and was not followed in the parent unit or in any child unit.

We traced the consent path end to end, because it was the one with legal consequence. A preference page reads the subscriber, a script writes the opt-in state back to the customer record, an hourly job pulls the last day of changes into a journey table, and a weekly job replaces that table entirely. Single and double opt-in run as separate branches of one journey, with a bounce check three days later that revokes consent if the confirmation never arrived. It is a reasonable design. It was held in one person's head.

We also documented the access model, because it was not what anyone assumed. National marketing users were assigned the full administrator role and then had permissions taken away one by one. An eight-item deny list rather than a set of granted rights. Two hundred and seventy-four users existed across eighty-six email domains, most of them outside the client's own. IP allowlisting was off, sessions ran for eight hours, and logins never expired through inactivity.

Then we drew it. Every diagram in the report was made for the report: the platform ecosystem, the business unit hierarchy, the core data model, and a flow for each automation and journey, showing which fed which. Where behaviour depended on code, the code went in the document, with credentials stripped.

Finally we scored the two active national units against nine dimensions. Three of them (data quality, consent compliance and internal consistency) we returned unscored, and said so, because the evidence to score them honestly did not exist in the platform. A confident number there would have been the most useful-looking and least true thing in the report.

The client received a platform assessment report, a set of diagrammed flows and automations, and a data dictionary for the critical data extensions and custom objects. All three were written to be usable without us by an internal team, an incoming partner, or an auditor.

The finding that mattered most was not a defect. It was that the marketing platform's behaviour was largely decided in the CRM: the key data extensions were synchronised from it, consent was stored in it, and the whole event programme was a custom application built on it with the marketing platform doing only the sending. Any plan that treated the two as separate systems was going to be wrong from the first line.

The unscored dimensions did more work than the scored ones. Naming an area as unmeasurable is a finding. It tells you the next piece of work is instrumentation, not optimisation, and it stops a roadmap being built on a number somebody made up.

We are not naming the client. An assessment of this kind maps exactly where a platform is soft, and that map is theirs, not ours.