Conditional Logic in Laravel Forms: When Fields Should Show (and Hide) | FilaForms [ ![Filaforms Logo](https://filaforms.app/logo.svg)FilaForms ](https://filaforms.app) [ Documentation ](https://docs.filaforms.app) [ Blog ](https://filaforms.app/blog) [ Try Demo ](https://filaforms.app/login) [ Documentation ](https://docs.filaforms.app) [ Blog ](https://filaforms.app/blog) [ Try Demo ](https://filaforms.app/login) ![FilaForms](https://filaforms.app/logo.svg) FilaForms TutorialsConditional Logic in Laravel Forms: When Fields Should Show (and Hide) ====================================================================== filaforms.app/blog [ Back to blog ](https://filaforms.app/blog) [ Tutorials ](https://filaforms.app/blog/category/tutorials) Conditional Logic in Laravel Forms: When Fields Should Show (and Hide) ====================================================================== Manuk Minasyan · April 16, 2026 · 9 min read You've built a form with ten fields, and half of them only matter sometimes. A "Company Name" field that nobody filling out a personal inquiry should ever see. A "Budget Range" dropdown that makes no sense until someone picks "Enterprise" from the plan selector. You know the drill. Most developers handle this with custom JavaScript. You wire up event listeners, toggle CSS classes, and pray nothing breaks when you add a new field next month. It works, but it's fragile, and the server has no idea which fields were actually visible when the user submitted. Conditional logic solves this properly. Fields appear and disappear based on what the user has already entered, and the same rules run on both client and server so nothing gets out of sync. [\#](#what-were-building "Permalink")What we're building -------------------------------------------------------- I'll walk through setting up conditional field visibility in FilaForms, the [form builder plugin for Filament](https://filaforms.app/blog/how-to-add-public-facing-forms-to-your-filament-app). By the end, you'll have a support ticket form where different fields show up depending on the issue type the user selects. But first, the feature needs to be turned on. [\#](#enabling-the-feature-flag "Permalink")Enabling the feature flag --------------------------------------------------------------------- Conditional visibility is behind a feature flag. It's disabled by default, which means you need to opt in before any of this works. In your `config/filaforms.php`, add the feature to your enabled features array: ``` use FilaForms\Enums\FilaFormsFeature; 'features' => [ FilaFormsFeature::FIELD_CONDITIONAL_VISIBILITY, // ... your other enabled features ], ``` Once that's in place, you'll see visibility options when editing fields in the form builder. [\#](#visibility-modes "Permalink")Visibility modes --------------------------------------------------- Every field starts as `ALWAYS_VISIBLE`, which is the default behavior you'd expect. Conditional logic gives you two more options: **SHOW\_WHEN** hides the field by default. It only appears when your conditions are met. Use this for fields that are exceptions rather than the rule. If 80% of respondents won't need "Company Name," hide it until someone picks "Business" as their account type. **HIDE\_WHEN** does the opposite. The field is visible by default and disappears when conditions match. This is less common, but useful when you want to remove a field in specific scenarios. Say you have a "Preferred contact time" field that should disappear when someone selects "Email only" as their contact method. I use SHOW\_WHEN about 90% of the time. HIDE\_WHEN has its place, but if you find yourself using it a lot, you might be overcomplicating your form logic. [\#](#building-your-first-condition "Permalink")Building your first condition ----------------------------------------------------------------------------- A condition has three parts: the target field (referenced by its `field_code`), an operator, and the expected value. Let's say you have a "Type" select field with options "Personal" and "Business." You want a "Company Name" text field to appear only when someone picks "Business." In the form builder, you'd configure the Company Name field like this: - Visibility mode: `SHOW_WHEN` - Target field: `type` (the field\_code of your select) - Operator: `equals` - Value: `Business` When a user selects "Business" from the Type dropdown, the Company Name field slides in. Pick "Personal" and it's gone. No page reload, no custom JavaScript. FilaForms handles it through Alpine.js on the frontend using Filament's `visibleJs` method, so the response is instant. [\#](#the-eight-operators "Permalink")The eight operators --------------------------------------------------------- FilaForms gives you eight operators. Which ones are available depends on the field type. For **text and string fields**: `equals`, `not_equals`, `contains`, `not_contains`, `is_empty`, `is_not_empty`. The `contains` operator is useful when you need partial matching. If someone types "urgent" anywhere in a description field, you could show a priority selector. For **numeric, float, date, and datetime fields**: `equals`, `not_equals`, `greater_than`, `less_than`, `is_empty`, `is_not_empty`. The comparison operators open up some practical use cases. Show a "bulk discount code" field only when quantity is `greater_than` 10. Show an "extended warranty" option when the order total exceeds a threshold. For **boolean fields**: `equals`, `is_empty`, `is_not_empty`. Pretty straightforward. "Do you need installation?" equals true? Show the address fields. For **single choice fields** (dropdowns, radio buttons): `equals`, `not_equals`, `is_empty`, `is_not_empty`. This is your most common conditional logic scenario, like the Type/Company Name example above. For **multi-choice fields** (checkboxes, multi-selects): `contains`, `not_contains`, `is_empty`, `is_not_empty`. Note the difference from single choice. Since multiple values can be selected, you check whether the selection *contains* a specific value rather than whether it *equals* it. [\#](#andor-logic "Permalink")AND/OR logic ------------------------------------------ A single condition is often enough. But sometimes you need more specificity. FilaForms supports two logic modes: **ALL (AND)** requires every condition to be true. Show the "Enterprise onboarding" section only when plan equals "Enterprise" AND company\_size is greater\_than 50. Both must match, or the field stays hidden. **ANY (OR)** triggers when at least one condition matches. Show a "Special requirements" field when category equals "Catering" OR category equals "Events." Either one is enough. You pick the logic mode per field, and all conditions on that field follow the same mode. If you need something more complex (like "(A AND B) OR C"), you'll want to restructure your form to avoid that level of nesting. In practice, I've rarely needed anything beyond straightforward AND or OR. [\#](#cascading-visibility "Permalink")Cascading visibility ----------------------------------------------------------- This is where things get interesting. If field B depends on field A, and field C depends on field B, FilaForms builds a dependency graph. When field A's value changes and B gets hidden, C automatically hides too. You don't configure this separately. It just works. If a parent field becomes invisible, all its dependents cascade down. This matters when you're building [multi-step forms](https://filaforms.app/blog/multi-step-forms-in-filament-a-complete-guide) with conditional sections. A whole branch of fields can appear or disappear based on a single selection at the top of the chain. The dependency graph prevents orphaned fields from showing up without their context. [\#](#the-always-save-option "Permalink")The "Always Save" option ----------------------------------------------------------------- By default, when a field is hidden (because its conditions aren't met), its value doesn't get saved to the submission. That makes sense most of the time. If someone never saw the "Company Name" field, there's nothing meaningful to store. But sometimes you want to keep the data. Maybe a field had a default value that's still relevant even when hidden. Or maybe you're using hidden fields to carry metadata through the form. That's what the "Always Save" toggle does. Enable it on a field, and its value gets persisted to the submission regardless of whether the field was visible when the user hit submit. Be deliberate with this. If you enable Always Save on everything, you'll end up with submissions full of empty or default values from fields the user never interacted with. Only use it when you have a specific reason. [\#](#server-side-consistency "Permalink")Server-side consistency ----------------------------------------------------------------- One thing worth calling out: the same conditional logic runs on the server during submission processing. This isn't just a frontend trick. When a form gets submitted, the backend evaluates the same conditions and determines which fields were actually visible. This means you can't bypass visibility rules by manipulating the DOM. If a field's conditions aren't met server-side, it gets treated as hidden regardless of what the frontend showed. Alpine.js handles the client side, PHP handles the server side, and they agree on the outcome. The user gets instant feedback in the browser, and the server enforces the same rules during processing. [\#](#putting-it-together-a-support-ticket-form "Permalink")Putting it together: a support ticket form ------------------------------------------------------------------------------------------------------ Let me walk through a realistic example. You're building a support ticket form with an "Issue Type" select that has three options: Bug Report, Feature Request, and Billing Question. Depending on what someone picks, you want different follow-up fields: **For Bug Reports:** - "Steps to Reproduce" (textarea, SHOW\_WHEN issue\_type equals "Bug Report") - "Browser/Environment" (text, SHOW\_WHEN issue\_type equals "Bug Report") - "Severity" (select with Low/Medium/High/Critical, SHOW\_WHEN issue\_type equals "Bug Report") - "Screenshot Upload" (file, SHOW\_WHEN severity equals "Critical") - this one cascades from Severity, which itself depends on issue\_type **For Feature Requests:** - "Use Case Description" (textarea, SHOW\_WHEN issue\_type equals "Feature Request") - "Priority for Your Team" (select, SHOW\_WHEN issue\_type equals "Feature Request") **For Billing Questions:** - "Invoice Number" (text, SHOW\_WHEN issue\_type equals "Billing Question") - "Amount in Question" (number, SHOW\_WHEN issue\_type equals "Billing Question") Common fields like "Subject," "Email," and "Description" stay visible for all issue types. Notice the cascading behavior on the Bug Report path. The "Screenshot Upload" field only appears when severity is "Critical," but severity itself only appears when the issue type is "Bug Report." If someone switches from "Bug Report" to "Feature Request," both severity and the screenshot upload disappear together. The dependency graph handles it automatically. This kind of form would take a fair amount of custom JavaScript to build from scratch. With conditional visibility in FilaForms, you configure it through the UI without writing any frontend code. The same form, if you were [building a contact form](https://filaforms.app/blog/building-a-contact-form-in-laravel-with-filament-step-by-step) manually, would need event listeners, state management, and duplicated validation logic between client and server. [\#](#a-few-things-ive-learned "Permalink")A few things I've learned -------------------------------------------------------------------- Keep your conditions simple. If you need more than two or three conditions on a single field, your form might be doing too much. Split it into separate forms or use a multi-step approach. Test the cascading behavior by changing parent fields after filling in child fields. Make sure the UX feels right when fields appear and vanish. Users shouldn't feel like they lost data they just entered. Use `is_empty` and `is_not_empty` more than you think you need to. They're great for progressive disclosure, where you reveal the next section only after the user has filled in the current one. And remember the Always Save gotcha. Review which fields have it enabled before you start analyzing submission data. Nothing is more confusing than seeing values for fields the respondent never saw. --- If you're building forms in Filament and want conditional visibility without wiring up custom Alpine components, [FilaForms](https://filaforms.app) handles the logic layer for you, both in the browser and on the server. Related posts ------------- [ Tutorials Apr 9, 2026 Multi-Step Forms in Filament: A Complete Guide ------------------------------------------------ Long forms kill completion rates. You already know this. If you've ever put 15 fields on a single page and wondered why nobody finishes it, the answer is o ](https://filaforms.app/blog/multi-step-forms-in-filament-a-complete-guide) [ Tutorials Apr 2, 2026 Form Submission Tracking and Analytics in Laravel — Without Third-Party Tools ------------------------------------------------------------------------------- You built a form. You embedded it on your site. People are submitting it. But how many people saw the form and didn't submit? How many started filling it o ](https://filaforms.app/blog/form-submission-tracking-and-analytics-in-laravel-without-third-party-tools) [ Tutorials Mar 26, 2026 Building a Contact Form in Laravel with Filament (Step-by-Step) ----------------------------------------------------------------- Every Laravel app eventually needs a contact form. And every time, you end up writing the same boilerplate: a controller, a form request, validation rules, an email notification, a Blade view, maybe a CSRF token check you forgot about. It works, but it's a lot of wiring for something this common. ](https://filaforms.app/blog/building-a-contact-form-in-laravel-with-filament-step-by-step) ![FilaForms Logo](/logo.svg) FilaForms Laravel form infrastructure for Filament. Stop rebuilding forms on every project. ### Product [ Documentation ](https://docs.filaforms.app) [ Blog ](https://filaforms.app/blog) [ Features ](https://filaforms.app#features) [ Contact ](mailto:hello@filaforms.app) ### Legal [ Terms of Service ](https://filaforms.app/terms-of-service) [ Privacy Policy ](https://filaforms.app/privacy-policy) © 2025-2026 FilaForms. All rights reserved. [ ](mailto:hello@filaforms.app) [ ](https://x.com/MinasyanManuk)