Tier 1 · Configuration
Renaming or retiring a field looks safe from the configuration screen. The risk lives everywhere else: the forms that place it, the workflows and triggers that read it, the list views and search scopes built on it, and the document templates that merge it into client-facing letters. This audit builds a per-field dependency register covering all of them, so every change starts with the full picture instead of a hopeful guess. It also closes the loop on the configuration audit: a never-populated field is only safe to retire once the register confirms nothing still reads it, and a duplicated field is only safe to consolidate once you know which copy each consumer uses.
Every form and aspect that places the field, with the phase and work-type scope of each placement, so a change is assessed against everywhere users actually see it.
The same concept captured under more than one key or on more than one form, so data splits across copies. The configuration audit already measures this defect (it found 5 logical fields duplicated across raw keys in the synthetic demonstration corpus); the register adds the missing half: which copy each consumer reads, so consolidation keeps the right one.
Workflows, triggers, guards, and business rules that read or write the field: the places where a rename silently stops automation, without an error to alert anyone.
List views, columns, and search scopes built on the field, which fail quietly rather than loudly when it changes.
Document templates, email templates, and content blocks are analysed to find where the field is merged into generated documents. Our document-analysis engine has mapped more than 4,000 template variables on live migration work; here it answers a different question: which precedents break if this field changes?
The register rolled up per field: a ranked list of the fields with the widest reach, a zero-consumer list that turns the configuration audit's dead fields into safe retirement candidates, and a rename-or-retire safety checklist for each change.
Configuration (forms, aspects, workflows, triggers, list views, and search scopes) is captured read-only through the administration API; document and email templates are exported and analysed by the same document-analysis engine we use on migration work. This tier consumes configuration and template definitions only, so no matter content and no personal data are read.
One intake field, scheduled for renaming during a form clean-up, turned out to have 31 consumers across six kinds of surface: 6 forms and aspects placing it, 5 workflows and 3 triggers reading it, 4 list views and 2 search scopes built on it, and 11 document templates that would have merged a blank into client-facing letters where the value used to be.
Change with confidence. Every field change ships with its dependency register and a rename-or-retire safety checklist, so configurators stop discovering consumers in production. Template owners get the same register inverted: for each precedent, the fields it merges, so retesting after a change becomes a checklist rather than a hunt through the template library.
