How to separate data, logic and interface

Your FileMaker system worked well for years — until it didn't. Now, changing a single field on a layout somehow breaks a calculation three screens away, and nobody is quite sure why. Every update becomes a risk, every new feature takes twice as long, and onboarding a new developer means weeks of archaeology. This article walks you through how to structurally separate data, business logic, and user interface in a FileMaker-based system — and why that separation is the single most important thing you can do for long-term maintainability.

Why does tightly coupled software become such a problem?

Tight coupling happens gradually. Someone needs a total on a layout fast, so they put a calculated field directly in the portal row. A business rule — "orders under €500 don't need manager approval" — gets hardcoded into a button script on one specific layout. A conditional formatting rule quietly doubles as a data-validation mechanism. None of these decisions feel wrong at the time. But over months and years, the system becomes a web of invisible dependencies.

The practical consequence: a developer changes the label on a status field and accidentally breaks the approval workflow on a layout they didn't even open. Or a new integration partner asks for an API endpoint, and you discover that the "logic" they need is scattered across fourteen layout scripts with no single authoritative source.

This is not a FileMaker problem specifically — it's the classic big ball of mud anti-pattern in software architecture. But FileMaker's flexibility makes it especially easy to fall into, because the tool lets you embed logic almost anywhere.

What does the three-layer model actually mean in practice?

The principle comes from established software architecture: separate your system into three distinct concerns.

1. Data layer — raw facts, nothing more. Tables, fields, relationships. No embedded business meaning, no formatting, no rules.
2. Logic layer — all business rules, calculations, validations, and workflows. This is where "an order over €5,000 needs a second approval" lives — in one place, called consistently.
3. Presentation layer — layouts, portals, web interfaces, mobile screens. Pure display and interaction. It reads from the logic layer; it does not contain logic itself.

When these three layers are clean and separate, you can change how something looks without touching how it works. You can update a business rule in one script and have it apply everywhere. And you can expose your logic to a new channel — a web app, a mobile client, an AI assistant — without rewriting anything.

How do you identify where your system is tangled?

Before you can fix the architecture, you need to find the knots. A practical audit looks like this:

Signs your data layer contains logic:

• Calculated fields that encode business rules (e.g., Case(status = "pending" and amount > 5000; "needs approval"; "auto-approve")) stored directly in table definitions
• Fields whose value is only meaningful in combination with a layout-specific context
• Summary fields used not for reporting but to drive workflow decisions

Signs your logic is scattered across the UI:

• Button scripts that are 80 lines long and mix navigation, validation, and data manipulation
• The same business rule copy-pasted into scripts on three different layouts
• Conditional formatting rules that also serve as implicit data validation
• "If the user is on Layout X, do Y" logic embedded in scripts that should be layout-agnostic

Signs your presentation layer is doing too much:

• Layouts that only work correctly if fields are in a specific tab order
• A report layout that breaks if you add a new status value to a field
• Web or mobile users getting different business rule outcomes than desktop users because the rule lives in a desktop-only layout script

How do you centralize business logic in FileMaker?

The most practical approach is to move all business rules into a dedicated set of scripts that behave like service functions — callable from anywhere, with no dependency on which layout is currently open.

Step 1: Identify every business rule in the system. Make a list. "Order approval threshold," "invoice numbering logic," "stock reservation on order confirmation." Write them down as named rules, not as descriptions of layouts.

Step 2: Create a dedicated script folder (or module) per domain. For example: Orders > Validate, Orders > Approve, Orders > Create. These scripts receive parameters, execute the rule, and return a result. They never navigate to a layout. They never assume what screen the user is on.

Step 3: Replace embedded logic with calls to these central scripts. A button on a layout no longer contains the approval logic — it calls Orders > Approve and handles the result (success, error, redirect). The rule itself lives in exactly one place.

Step 4: Use a consistent parameter-passing pattern. FileMaker's Get(ScriptParameter) and JSON functions make it practical to pass structured data to scripts. Define a convention early and stick to it — e.g., always pass a JSON object with a recordId and an action key. This is the foundation for making your logic layer callable from external systems via the FileMaker Data API.

How do you keep the data layer clean?

The data layer should be boring. Tables, fields, relationships — and as little else as possible.

• Avoid calculation fields that encode business rules. A field like ApprovalStatus that calculates its own value based on amount thresholds is a business rule, not a data fact. Move it to the logic layer; store the result back as a plain data field after the script runs.
• Separate raw data from derived data. Raw: OrderDate, CustomerID, TotalAmount. Derived: DaysOverdue, ApprovalStatus, RiskCategory. Derived values should be written by logic-layer scripts, not auto-calculated in field definitions — unless the calculation is genuinely just formatting or arithmetic with no business meaning.
• Keep your schema stable and semantics-neutral. A field called Status with values 1, 2, 3 forces every layout and every integration to know what those numbers mean. A field with values draft, pending_approval, approved is self-documenting and survives UI changes.
• Document your relationships. In a tightly coupled system, relationship graphs quietly become load-bearing walls. Draw the intended data model separately from the FileMaker relationship graph — they should match.

How do you build a presentation layer that stays in its lane?

A well-separated UI layer does exactly two things: it displays data and captures user intent. It does not make decisions.

Practical rules for layouts:

• A layout script should never contain more than ~10 lines. Its job is: validate input, call a logic-layer script, handle the result, navigate if needed.
• Never put the same navigation or validation logic in more than one layout script. If you find yourself copy-pasting, that logic belongs in the logic layer.
• Treat each layout as a view — it renders a state. The state itself lives in the data layer; the transitions live in the logic layer.
• If you're building a web interface or mobile app on top of FileMaker (via the Data API or a custom web app), this discipline pays off immediately: your web front-end can call the same logic-layer scripts as the FileMaker layouts, with identical results.

What does this unlock beyond easier maintenance?

Clean layer separation is not just a housekeeping exercise. It's the prerequisite for almost every meaningful capability upgrade:

• API integration: An ERP like Exact Online or AFAS can call your logic layer directly via the FileMaker Data API. The integration doesn't need to understand your layouts — just your business rules. An order that comes in via the API runs through the same Orders > Validate script as an order entered manually in FileMaker.
• Web and mobile extensions: A web portal for customers can use the same logic layer as your internal FileMaker system. No duplicated rules, no sync problems.
• AI tooling inside the workflow: An AI assistant that suggests order classifications or flags anomalies needs a clean data model and predictable logic hooks to work reliably. If your business rules are scattered across layouts, the AI can't reason about them consistently.
• Onboarding new developers: A new team member can read your script folder structure and understand the system's behavior without reverse-engineering fourteen layouts.

Checklist: Is your system architecturally separated?

• Every business rule exists in exactly one named script, not in multiple layout scripts
• Layout scripts are thin: they call logic-layer scripts and handle results, nothing more
• Calculated fields in table definitions contain only arithmetic or formatting, not business decisions
• Derived data (status, flags, categories) is written by scripts, not auto-calculated from field definitions
• Your field naming is self-documenting and semantics-neutral
• A new integration (API, web app, mobile) could call your logic layer without touching any layout
• You can change a layout without fear of breaking a business rule
• You can change a business rule in one place and know it applies everywhere

FAQ

Does this mean rewriting the entire system from scratch? No. Layer separation can be done incrementally. Start with your highest-pain area — typically the most-changed workflow — and extract its business logic into central scripts. Each refactored module reduces risk for the next one. A full rewrite is rarely necessary and often counterproductive.

What if our business rules are genuinely complex and hard to isolate? That's often a sign the rules haven't been fully documented, not that they can't be separated. Start by writing down what the rule should be in plain language. If that's hard, it means the system has drifted from the intended business logic — which is a separate (and important) problem to solve before refactoring.

How does this work with the FileMaker Data API? The Data API exposes your FileMaker data and can trigger scripts. If your logic layer is a clean set of named scripts, any external system can call them by name with a JSON payload — essentially treating your FileMaker system as a set of microservices. This is how a well-architected FileMaker system integrates with REST-based platforms like Zapier, Make, or a custom web app without fragile workarounds.

Can AI tools be added to a tightly coupled system? Technically yes, but the results are unreliable. AI integrations — whether that's a classification model, an anomaly detector, or a generative assistant — need clean, consistent data and predictable logic hooks. A tangled system gives the AI inconsistent inputs and no reliable way to act on its outputs. Clean architecture is the prerequisite.

How long does a typical separation project take? For a mid-sized FileMaker system (50–150 tables, 5–15 active workflows), a structured refactoring project typically runs 3–6 months in focused sprints, with the system remaining live throughout. The first sprint usually delivers the most visible improvement in the most-used workflow.

---

If your system has reached the point where every change feels like defusing a bomb, the architecture described here is the way out — and it's achievable without starting over. At Loggix, we work with businesses to untangle exactly these situations: mapping the current system, separating layers incrementally, and where relevant, extending the result with API integrations, web interfaces, or AI tooling inside the workflow. If you'd like a concrete assessment of where your system stands, that conversation is a practical place to start.