I’m working on a Zapier application using their CLI tools and ran into an issue with dynamic field dependencies.
I have two dropdown fields that get their options from API calls. The second field depends on what gets selected in the first one.
inputFields: [
{
key: 'projectId',
label: 'Project',
required: true,
type: 'text',
helpText: 'Select a project',
dynamic: 'project.id.name',
altersDynamicFields: true,
},
{
key: 'taskId',
label: 'Task',
required: true,
type: 'string',
helpText: 'Select a task',
dynamic: 'task.task_id',
}
]
The problem happens when someone picks both fields, then goes back and changes the first field. The second field keeps its old value even though the options have updated. When you open the dropdown again, you can see the new choices are there, but the previously selected value doesn’t get wiped out.
This creates a problem because the old selection might not be valid anymore. Is there a way to automatically reset the dependent field when the parent field changes?
Had this exact same problem last year with a location-based integration. Zapier doesn’t clear dependent fields automatically, so you end up with stale values hanging around. Here’s what fixed it for me: modify your dependent field’s dynamic function to include the parent field value as a parameter. When the parent changes, it forces the dependent field to completely re-evaluate. In your task dynamic function, reference the projectId parameter and return an empty result if no project’s selected. This clears the field since there’s nothing to display. I also added explicit field dependencies in the schema - make sure your task field references projectId in its dynamic key structure. Users still have to manually reselect the dependent field, but at least they won’t see invalid options or phantom selections.
Had this exact problem 6 months ago building a Zapier integration for project management. Zapier doesn’t auto-clear dependent fields when parent values change, so you get invalid combinations. Here’s what worked for me: Add validation in the task field’s dynamic function to check if the selected task actually belongs to the selected project. If it doesn’t, return an empty array or throw a validation error. Forces users to pick again. Alternative approach: Use a computed field that validates the projectId/taskId relationship before the action runs. The computed property checks if the task belongs to the project and clears taskId if there’s no match. Key thing - handle this validation server-side in your dynamic functions. Don’t rely on Zapier’s UI to reset fields automatically. Not the prettiest solution, but it stops users from submitting invalid combinations.
Hit the same issue building a Zapier app. Add a computed field that validates the dropdown relationship. When projectId changes, return null from your task field’s dynamic function if there’s no valid match. Zapier shows the field as empty and forces reselection. Hacky but reliable.