Custom Field impact analysis / dependency audit
J
Joseph Plaizier
As a workspace administrator, I regularly need to rename, replace, or remove custom fields as our processes evolve. The problem is there's currently no way to determine where a custom field is being referenced across the workspace. Dashboards, views, automations, and forms can all be configured to use a specific custom field, but there's no reverse-lookup to tell me which of those are affected before I make a change.
Right now, the only option is to manually open every dashboard, every view, and every automation to check whether a given field is in use. In a large workspace with dozens of dashboards and hundreds of views, that's not realistic. It means admins are either spending hours auditing by hand or making changes and hoping nothing breaks.
What I'd like to see is an impact analysis tool, ideally accessible from the Custom Field Manager, that shows everywhere a custom field is referenced. Something like:
+ Dashboard cards using the field (as a filter, grouping, or data source)
+ Views filtering or grouping by the field
+ Automations referencing the field in triggers, conditions, or actions
+ Forms that include the field as a question
+ Super Agents that have the field as a reference or are programmed to update the field
This would give admins the confidence to clean up, consolidate, and improve their custom field structures without the risk of silently breaking downstream reporting or workflows. It would also make onboarding new admins much easier, since they could understand field dependencies without institutional knowledge.
I imagine this would be valuable for any workspace at scale, but especially for teams on Business Plus and Enterprise plans where custom field governance is a real operational concern.
Log In