You've built a major new feature for your FileMaker solution. It's tested and ready. But deploying it to all users simultaneously feels risky. What if there's an edge case you missed? What if users hate the new workflow? What if the feature performs poorly with production data volumes?

You have two bad options: delay the release indefinitely while trying to anticipate every possible issue, or push it live and hope for the best. When problems emerge, your only fix is another full deployment to roll back the changes.

Feature flags , toggleable switches that control whether functionality is active, let you deploy code without immediately exposing it to users. You can enable features for specific users, gradually roll out to larger groups, or instantly disable problematic functionality without touching code. These can also be a nice way to monetize certain feature upgrades per client.

FileMaker developers can implement feature flags using tables, privilege sets, and smart scripting patterns. This article shows you how to build a feature flag system that makes your FileMaker deployments safer, more controlled, and reversible. I'll also discuss considerations for avoiding technical debt through implementing these feature flags.

What Are Feature Flags?

Feature flags (also called feature toggles) are configuration settings that control whether specific functionality is available. Instead of deploying new code that immediately affects all users, you deploy code wrapped in conditional logic that checks a flag before executing.

In practice, this means:

New invoice workflow is deployed but disabled by default
You enable it for your internal testing team first
After verification, you enable it for 10% of users
If successful, you gradually increase to 100%
If problems arise, you instantly disable it without redeploying

The code exists in production, but the flag determines who sees it and when.

Why FileMaker Developers Need Feature Flags

FileMaker's rapid development cycle makes deploying changes easy --- sometimes too easy. Feature flags add a control layer that traditional FileMaker workflows lack:

Safer deployments: New features can be deployed without immediately impacting users. Test in production with real data before full rollout.

Instant rollback: When issues arise, disable the feature immediately rather than scrambling to deploy a fixed version.

Gradual rollouts: Expose new functionality to small user groups first. Catch issues affecting specific workflows or data patterns before they impact everyone.

A/B testing: Run two versions of a workflow simultaneously and measure which performs better or gets better user adoption.

Beta programs: Let power users opt into experimental features while keeping the main user base on stable functionality.

Scheduled releases: Deploy code on your schedule, activate features on the business's schedule. Marketing can plan announcements knowing features activate on specific dates.

The Basic Feature Flag Architecture

A FileMaker feature flag system needs three components: flag storage, flag checking, and flag management.

Component 1: Flag Storage Table

Create a FeatureFlags table to store flag definitions and states:

Fields:

FlagID (auto-enter serial)
FlagName (text, indexed, unique)
Description (text)
IsEnabled (number, 0 or 1)
CreatedDate (timestamp)
ModifiedDate (timestamp, auto-enter on modification)
ModifiedBy (text, auto-enter Get(AccountName))

Component 2: Flag Checking Function

Create a custom function IsFeatureEnabled ( flagName ) that determines if a flag is active in the system:

// Custom Function: IsFeatureEnabled ( flagName )
// Returns: 1 if feature is enabled, 0 if not
Let ( [
~enabled = ExecuteSQL (
"SELECT IsEnabled
FROM FeatureFlags
WHERE FlagName = ?";
""; ""; flagName
)
];
~enabled = 1
)

This function encapsulates all flag logic in one place. Scripts and calculations call it to determine if features should be active. The nice part about ExecuteSQL is that you don't need to build out the relationship to the FeatureFlags table in every context where you might need to call it. Assuming your feature list is not 100,000 features big, this can be minimal on performance impact.

Component 3: Flag Management Interface

Create a simple management layout based on the FeatureFlags table where administrators can:

View all flags with current status
Toggle flags on/off
See modification history

This interface should be restricted to administrators via privilege sets.

Pro-Tip: If you have a central solution where you manage all your clients, build out the feature enrollment in your central solution as well and use the Data API to query which features are enabled for the client when launching the solution. This allows you to manage all your clients for your solution within a single interface that only you have access to.

Implementation Patterns

Once your infrastructure exists, apply feature flags to different scenarios:

Pattern 1: Script-Based Features

Wrap new functionality in conditional checks:

# Script: ProcessOrder_New
If [ IsFeatureEnabled ( "new_order_workflow" ) ]
  # New workflow code
  Perform Script [ "ProcessOrder_NewVersion" ]
Else
  # Existing workflow code
  Perform Script [ "ProcessOrder_Original" ]
End If

This lets you deploy both workflows simultaneously. The flag determines which executes.

Pattern 2: UI Element Visibility

Control whether buttons, portals, or layout sections appear:

Button visibility calculation:

IsFeatureEnabled ( "advanced_reporting" )

Set this as the button's Hide Object When calculation. The button only appears when the flag is enabled.

Tab panel conditional:

If [ IsFeatureEnabled ( "analytics_tab" ) ]
 Go to Object [ "AnalyticsTab" ]
Else
 Show Custom Dialog [ "Feature Not Available"; "This feature is not yet enabled for your account." ]
End If

If you are concerned about performance especially in list views and portals, I would suggest setting a global variable like $$THIS.FEATURE.ENABLED with the the SQL call and then having layout objects reference that global flag so that it is only evaluated once.

Pattern 3: Layout Switching

Offer new layouts while keeping old ones available:

Script: NavigateToInvoices

If [ IsFeatureEnabled ( "redesigned_invoice_layout" ) ]
 Go to Layout [ "Invoices_New" ]
Else
 Go to Layout [ "Invoices_Original" ]
End If

Users get automatically routed to the appropriate version based on flag status.

Pattern 4: Calculation Field Behavior

Change calculation logic based on flags using Case statements:

// Field: Invoice::CalculatedTotal
Case (
 IsFeatureEnabled ( "new_tax_calculation" ) ;
 Sum ( LineItems::NewTaxAmount ) ;
    // Original calculation
    Sum ( LineItems::OriginalTaxAmount )
)

This works for unstored calculations that evaluate in real-time. For stored calculations, you'll need script-based updates.

Best Practices and Conventions

Naming conventions: Use descriptive, hierarchical names like newinvoice_workflow, beta_advanced_search, or experiment_dashboard_layout_v2. Prefixes like new, beta*, or experiment* indicate the flag's purpose and expected lifecycle.

Documentation: Fill in the Description field for every flag. For example:

FlagName: new_inventory_tracking Description: Replaces Excel-based inventory with native FileMaker tracking. Includes barcode scanning and real-time stock levels. Target: Full rollout by Q2 2025

Lifecycle management: Feature flags should be temporary. Establish a cleanup process:

Short-term flags (experiments, A/B tests): 30--90 days maximum
Rollout flags (gradual releases): Remove after reaching 100% for 2+ weeks
Kill switches (emergency disable capability): Can remain indefinitely if risk warrants

Create a quarterly review script that flags old toggles for cleanup. Candidates for removal include flags enabled at 100% for over 30 days, flags with modified dates over 90 days ago, or flags that were never used.

Flag retirement process:

Flag reaches 100% rollout and stabilizes
Remove flag checks from code, making feature permanent
Delete flag from FeatureFlags table
Archive usage data for historical reference

IMPORTANT: Leaving dead flag checks in code creates technical debt and confusion.

What to Avoid

Pitfall 1: Over-flagging. Not every change needs a feature flag. Simple bug fixes and minor UI tweaks don't warrant the overhead. Reserve flags for major workflow changes, new modules or functionality, changes affecting critical business processes, or features requiring gradual rollout.

Pitfall 2: Permanent flags. Flags that never get removed accumulate, creating code complexity. Set expiration dates or review cycles to force cleanup decisions.

Pitfall 3: Flag dependency chains. Avoid complex webs where Flag A depends on Flag B which depends on Flag C. This makes reasoning about feature state nearly impossible. Keep dependencies shallow and well-documented.

Pitfall 4: Inconsistent checking. If a feature has ten entry points but only five check the flag, users will experience inconsistent behavior. Audit all code paths when implementing flags.

Pitfall 5: Performance impact. Every flag check is a database query (via ExecuteSQL in the custom function). For high-frequency operations, cache flag states in global variables that refresh periodically rather than checking on every execution:

// At script start or user login:
Set Variable [ $$FLAG_NewDashboard ; Value: IsFeatureEnabled ( "new_dashboard" ) ]
// In frequently-called scripts:
If [ $$FLAG_NewDashboard ]
 // New code
End If