New Prompts Not Appearing in Slate Form Conditions? Try Refreshing the Form Field
You add a new prompt to an existing Slate field.
The field is already mapped to a form. The new prompt appears correctly when someone interacts with the field itself.
Then you try to use that same prompt in conditional logic on the form.
It isn't there.
If you've encountered this behavior during cycle preparation or while updating an existing form, you may not need to remove and rebuild the field. A simple edit to the existing form field may be enough to force Slate to recognize the updated prompt list.
The Scenario
Consider a common cycle-prep example.
You have an existing system field for Academic Program or Major with a prompt list attached to it. That field has already been added to one or more forms.
For the new cycle, you add another program to the existing prompt list.
At first, everything appears to work:
- The new prompt exists on the system field.
- The existing form field reflects the updated prompt list.
- A user completing the form can select the new option.
The problem appears when you try to build conditional logic based on the newly added prompt.
When configuring a form condition, the new prompt may not appear as an available value.
The system field knows about it.
The form field displays it.
But the form's conditional logic does not.
Why This Can Be Confusing
This behavior can make it look like the prompt was configured incorrectly or that the form needs to be rebuilt.
In our testing, however, the issue appeared to be related to how Slate stores or refreshes the configuration associated with a field after it has already been added to a form.
A useful way to think about it is that the form appears to retain its own representation of the field configuration.
When the underlying system prompt list changes, the visible field may recognize the new prompt without every other component associated with that form field immediately recognizing the update.
This is particularly noticeable when configuring conditional logic.
We think of this as a form-level cache behavior, although that terminology describes the behavior we observed rather than an officially documented Slate architecture.
The Old Workaround
One way to resolve the problem is to:
- Inactivate the existing field on the form.
- Add the system field back to the form.
- Reconfigure the field as needed.
Once the field is added again, the updated prompts become available to the form's conditional logic.
Technically, it works.
Operationally, it isn't a great solution.
Imagine using this approach during annual cycle preparation. Every time a new major, program, term, location, or other prompt is added, you would potentially need to inactivate and recreate fields across your forms.
Over several cycles, that can leave you with multiple deprecated versions of the same field and unnecessary configuration clutter.
There is a much easier option.
The Better Fix: Refresh the Existing Form Field
Through testing, we found that making an edit to the existing field on the form can cause Slate to refresh the field configuration.
You do not need to remove the field.
Instead:
- Open the affected form.
- Edit the existing mapped field.
- Make a small change to the field configuration.
- Save the field.
- Return to the form condition and check the available prompt values.
The change can be minor.
For example, you might temporarily:
- adjust the form field label,
- add a character or space to the label,
- toggle an applicable field setting,
- or make another harmless configuration change.
Saving the field appears to refresh the form's stored configuration.
After doing so, the newly added prompt should become available when configuring conditional logic.
If you made a temporary cosmetic change, you can then revert it.
A Practical Example
Suppose your system field contains these values:
- Biology
- Chemistry
- Mathematics
That field has been used on an application form for several cycles.
For the upcoming cycle, you add:
- Data Science
When you open the form, Data Science appears as an available choice for the applicant.
But you want to display an additional question only when:
Academic Program = Data Science
When you create that condition, Data Science is missing from the list.
Rather than deleting and rebuilding the Academic Program field:
- Edit the existing Academic Program field on the form.
- Temporarily change the label from Academic Program to Academic Program*.
- Save the field.
- Reopen the field and restore the original label if desired.
- Return to your conditional logic.
The updated prompt list should now be available for the condition.
Why This Matters for Cycle Preparation
The individual fix is small.
The larger implication is much more important.
Cycle preparation often involves modifying existing prompt lists:
- adding new academic programs,
- updating entry terms,
- adding recruitment populations,
- changing event categories,
- introducing new campuses or locations,
- or expanding other institution-specific values.
If an existing form has been using that field for several cycles, new prompts may appear perfectly normal to the end user while remaining unavailable in conditional logic.
That creates a particularly frustrating troubleshooting scenario because there is no obvious indication that the form field itself needs to be refreshed.
Before rebuilding the field, try saving an edit to the existing field first.
It can keep your form cleaner and avoid creating years of unnecessary inactive field configurations.
Troubleshooting Checklist
If a newly created prompt is available on a form but missing from form conditional logic:
- Confirm the prompt exists on the correct system field.
- Confirm the form field is mapped to that system field.
- Confirm the new prompt appears when interacting with the field itself.
- Edit the existing form field.
- Make a small configuration change.
- Save the field.
- Reopen your conditional logic and check for the new prompt.
- Revert any temporary cosmetic changes if necessary.
If the prompt still does not appear, continue troubleshooting the underlying field and prompt configuration before replacing the form field entirely.
The Takeaway
When Slate behaves as though a form knows about a new prompt in one place but not another, the answer may not be to rebuild the configuration.
Sometimes the form simply needs a reason to refresh what it already knows.
Before inactivating and recreating an existing field, edit and save the field already on the form.
It is a small troubleshooting step that can make cycle preparation considerably cleaner.
No comments to display
No comments to display