Changing a field value should be a five-minute task.
Often, it isn't.
Imagine you've been asked to rename an Opportunity Stage in Salesforce, retire a status in NetSuite, or consolidate a value that several systems share. That value might be referenced by a Flow, checked inside an Apex trigger, used to control what appears on a page, relied on by a saved search or workflow rule, or watched by a Workato recipe that creates something somewhere else entirely.
Some dependencies live inside the system you're looking at. Others don't.
So before making the change, you need to answer a much bigger question: What will this actually affect?
“Where is this field used?” is usually not the real question.
You can ask dx0 where a field is used, and dx0 will search its understanding of your connected systems to find references to it.
But giving you five pages of references isn't particularly useful.
Because most of the time, you don't actually care about every place where the field appears. You're trying to do something.
Maybe you're renaming a stage. Retiring a value. Consolidating several values. Or redesigning a process that spans more than one system.
dx0 gives you the important context first, then helps you investigate what you're actually trying to change.
“I need to rename this stage value. What will it break?”
“Which automations depend on this exact value?”
“Does anything outside this system depend on it?”
“What needs to change before we can safely remove it?”
Follow the impact, not just the references.
Once dx0 understands what you're trying to do, it investigates accordingly.
You don't need to tell it to search Flows, then Apex, then workflow rules, then saved searches, then reports, then integrations.
dx0 understands the shape of your business systems and investigates the places that matter for the change you're considering.
That can include Salesforce and NetSuite configuration and automation, as well as the integrations and code sitting between them.
So if a Workato recipe fires when an Opportunity reaches Closed Won, dx0 can include that dependency in the investigation too.
Your dependencies don't stop at the edge of one system. Neither should your impact analysis.
Turn the investigation into a plan.
Finding the dependencies is only the beginning.
Once you understand the impact, you can keep working with dx0 to break the change into smaller, safer steps.
Ask what should change first, which dependencies need to be updated, what should be tested, and what needs to be coordinated with other systems or teams.
Instead of starting with a giant dependency list, you end with a plan for making the change.
And if you're using Claude, Cursor or another AI agent to implement the change, dx0 can provide this context through MCP so the agent understands the dependencies before it starts changing things.
Impact analysis should help you make the change.
Traditional where-used tools are good at answering:
“Where does this appear?”
dx0 helps you answer the question you probably meant:
“I need to change this. What do I need to know before I do?”
