[ Tables ] Allow Filtering Table Data Using State Variables (Before Data Is Saved)

[NDCallahan]

🧩 Feature: Allow Filtering Table Data Using State Variables (Before Data Is Saved)

📝 Description

Many Budibase apps rely on state variables to store temporary data during a user session — especially when working with multi‑step forms or related records that must be linked together before anything is saved to a database table.

A common pattern is:

1. Form 1 generates a UUID (or other unique identifier) and stores it in state.
2. Before Form 1 is submitted, the user opens Form 2, which uses that UUID to create related records.
3. Form 2 is submitted immediately, and its data is saved to a table.
4. The builder wants to display Form 2 results inside Form 1 before Form 1 is submitted.

Currently, Budibase does not allow filtering a table component using a state variable when the primary record (Form 1) has not yet been saved. This prevents builders from showing related data in real time, even though the UUID exists and is stored in state.

Builders should be able to filter table data using state variables, regardless of whether the primary form has been saved.

---

💡 Use Case

As a Budibase user, I want to:

• Generate a UUID in Form 1 and store it in state.
• Use that UUID to create related records in Form 2.
• Submit Form 2 immediately while Form 1 is still open.
• Display Form 2 results inside Form 1 using a table filtered by the UUID stored in state.
• Build multi‑step, relational workflows without forcing premature form submissions.

---

🔍 Current Pain Points

• Table components cannot filter using state variables when the main form has not been saved.
• Builders must create awkward workarounds (temporary tables, forced early saves, duplicated screens).
• Real‑time relational workflows become impossible.
• Users cannot see related data until after the primary form is submitted.
• This breaks common patterns like:
  • Parent → child record creation
  • Multi‑step wizards
  • Session‑based data collection
  • Temporary staging of related records

---

🎯 Expected Behavior

• Table components should allow filtering using:
  • State variables
  • Temporary values
  • Unsaved form fields
• Filtering should work even when the primary record has not yet been saved to a table.
• The table should update dynamically as related records are created.
• No need to save Form 1 just to enable filtering.

---

🚀 Why It Matters

• Enables true multi‑step form workflows.
• Allows relational data to be displayed immediately.
• Eliminates the need for premature form submissions.
• Makes Budibase more flexible for complex data‑entry scenarios.
• Supports common patterns used in CRMs, intake systems, applications, and onboarding flows.

---

📸 Screenshots

---

📌 Additional Notes

• This feature aligns with Budibase’s goal of supporting dynamic, state‑driven UIs.
• Even minimal support for state‑based filtering would unlock many advanced workflows.

---

✅ Contributor Interest

• I want to work on this PR if approved.