Skip to main content
Back to Blog
forms context ux automation

Smart Forms That Adapt to Context

Swifty Team Mar 6, 2026 3 min read

A form opened from a project detail page is not the same as a form opened from a global create button. In the first case, the project is known — it should be pre-filled automatically. In the second, the user needs to select it. A form opened in the context of a specific customer should show only options relevant to that customer. A form opened for a premium account should show fields not available for free accounts.

Context-aware forms adapt to where and how they're opened.

Pre-Fill from Parent Context

When a form opens inside a component that has a loaded record — a project detail, a customer card, a workspace context — it can read that context and pre-fill any matching fields automatically.

A task form opened inside a project detail pre-fills the project relation. A note form opened from a contact pre-fills the contact relation. An expense form opened in the context of a cost center pre-fills the cost center field. The form knows what it's being opened for and saves the user the step of selecting what's already obvious from context.

Option Filtering Based on Context

Select fields can show different options depending on parent context. A subcategory field might only show options valid for the selected main category. A territory assignment might only offer territories within a region. A product variant selector might filter to variants available for a specific configuration.

These relationships are defined in the field configuration — which field gates which options in which other field. The form evaluates them at runtime based on what's selected or inherited from context.

Conditional Visibility from Context

Entire form sections can be shown or hidden based on context. A "tax details" section might only appear for records in certain jurisdictions. A "priority customer" section might only show for accounts above a certain tier. An "advanced settings" section might only be visible to users with a specific role.

The form reads both data context and user context to decide what to display.

Consistent Behavior, Flexible Configuration

Context adaptation is configuration, not code. The form definition describes what to pre-fill, what to filter, and what to show or hide. The form component evaluates those rules at runtime against the current context. Changing the behavior requires changing the configuration — no development work.

This means non-developers can adjust form context behavior through the builder. Add a new pre-fill rule when a new relationship is established. Add a new conditional section when a new workflow emerges. The form adapts as the application evolves.

Related posts

Composed Data Sources

Chain and relate data sources for rich dashboards — compose complex data views from simpler sources without writing code.

Computed Expressions

Transform data with template expressions and built-in functions — format, combine, and derive values from your data without code.

Cross-Source Data Joins

Combine data from multiple sources in one view — join records from your database with data from external services using a shared key.