Visibility Conditions Should Support Source Screen Values

[nocodeandy]

Allow form-screen components to use values from the source screen (not just the destination table) for conditional visibility.

Summary

Today, component visibility in a form screen can only reference columns from the destination table (the table the form writes to). Builders cannot reference columns from the source screen that launches the form. This limits dynamic, context-aware forms that should react to the record a user came from.

Reference: Loom walkthrough – https://www.loom.com/share/c627d7dd419e466097f568233ee5c688

Current Problem

When configuring visibility rules on a form-screen component, the condition builder exposes only fields from the destination table. Source-screen fields (the record used to open the form) are not available. As a result, common patterns—like hiding/showing sections based on flags on the source record—cannot be implemented without duplicating state or awkward workarounds.

Examples/Scenarios

• Attachment requirement: Hide/show an “Attachments” container in the form based on a boolean on the source record (e.g., requires_attachment = true). This flag lives in the source screen, but the form can’t “see” it.
• Conditional follow-ups: Display additional questions if the originating task’s category (on the source) is “Incident” or “Return.”
• Role/permissions hints: Show guidance blocks when the source record’s priority or status indicates escalation, without having to mirror those values into the destination table.

Why This Matters

• Enables context-aware forms that adapt to the record users came from.
• Reduces data duplication and brittle workarounds (e.g., copying flags from source → destination just to drive UI).
• Aligns form behavior with detail screens, where visibility can already key off more contextual data, improving consistency and builder mental models.
• Lowers implementation time and risk for partners building multi-step flows.

Suggested UX

• In the form screen’s Visibility Conditions builder, add a new “Source Screen” (or “Origin Record”) section alongside “This Item / Destination Table.”
• Expose read-only fields from the source record used to open the form (including computed columns available there).
• Support the same operators as destination fields (equals, contains, is empty, etc.).
• Clearly label scopes in the UI (e.g., Source → Tasks.requires_attachment, Destination → Submissions.attachment) to avoid ambiguity.
• If multiple launch contexts are possible, default to the record instance that initiated the form; if none exists, treat source fields as null/undefined and surface a non-blocking builder warning.