How to test role-based access

You've just shipped a new module in your FileMaker system — maybe a finance dashboard, maybe an HR record layout — and three days later someone from sales calls to say they can see salary data they were never supposed to see. Or the opposite happens: a warehouse manager who absolutely needs to approve purchase orders gets a blank screen because their account was accidentally left out of the new privilege set. Both situations come from the same root cause: role-based access that was configured but never properly tested.

This article walks through a concrete, repeatable way to test role-based access in a custom business application, so you catch these problems before your users do — not after.

What is role-based access, in practical terms?

Role-based access control (RBAC) means every user is assigned a role — say, Sales Rep, Finance Manager, Warehouse Lead, or Admin — and that role determines exactly what they can see, edit, create, or delete inside the system. In a FileMaker solution this is usually built with privilege sets, but the same logic applies whether the underlying system is a custom web app, an ERP module, or an API layer sitting between systems.

The problem is that access rules are rarely tested with the same rigor as business logic. Teams test whether an invoice calculates correctly, but nobody sits down as "the intern account" and tries to open the payroll table. That gap is exactly where security incidents and embarrassing support tickets come from.

Why does role-based access break so often in custom software?

A few patterns show up again and again in real projects:

• New fields get added, but permissions don't follow. A developer adds a "Commission %" field to an existing layout. The privilege set was defined at the layout level, so every role that could see the layout can now see commission data too — including roles that shouldn't.
• Roles are copied, not designed. Someone duplicates the "Sales Rep" privilege set to quickly create "Sales Manager," tweaks two settings, and forgets to review the other twenty.
• Scripts run with full access. A script triggered by a low-privilege user is set to run "with full access privileges" for a legitimate technical reason, but that also silently bypasses record-level restrictions the user should have.
• Portals and related tables are overlooked. The main layout is locked down correctly, but a portal showing related records from another table still exposes fields nobody checked.
• External access points aren't covered. A privilege set is tested carefully inside the FileMaker client, but the same account also has API access or a web viewer connection that was never checked against the same rules.

None of this is caused by bad developers. It's caused by treating permissions as a one-time setup task instead of an ongoing thing you actively verify — the same way you'd verify a calculation or a report.

How do you actually test role-based access, step by step?

1. Build a role-permission matrix before you test anything. List every role down one side (Sales Rep, Finance Manager, Warehouse Lead, Admin, external API user, etc.) and every module, layout, field, and script down the other. Mark what each role should be able to view, create, edit, and delete. This matrix becomes your test plan — and your documentation.
2. Create one real test account per role. Don't test with your own admin account and "imagine" what a Sales Rep would see. Create an actual FileMaker account with the Sales Rep privilege set, log in as that account, and click through the system exactly as that person would on a Monday morning.
3. Test the negative case, not just the positive case. It's not enough to confirm a Finance Manager can see the ledger. You also need to confirm a Sales Rep cannot — try to navigate there directly, try a keyboard shortcut, try opening a related record through a portal.
4. Test scripts and buttons, not just layouts. A user might not have a menu item for a certain action, but if a button on a layout triggers a script with elevated privileges, they may be able to reach restricted data anyway. Click every button available to that role and check what it actually does.
5. Test record-level, not just layout-level, restrictions. In FileMaker this means checking calculated access conditions — for example, a rule that a Sales Rep can only edit orders where Creator = Get(AccountName). Log in as two different Sales Reps and confirm each can only touch their own records.
6. Test every access channel, not just the desktop client. If the same data is reachable through FileMaker Go, a WebDirect portal, a custom web app, or an API connector, each of those channels needs its own pass through the matrix — a rule enforced in the client isn't automatically enforced in the API.
7. Test what happens when roles change. Promote a test user from Sales Rep to Sales Manager mid-test. Confirm access updates immediately and that no cached session still shows the old permission set.
8. Document every result in the matrix. Turn each cell into pass/fail with a date. This turns your test into a living artifact you can hand to an auditor, a new developer, or your own future self six months from now.

How does this look with modern FileMaker tooling like Klai and FmBetterforms?

As FileMaker systems grow, teams increasingly extend them with tools like FmBetterforms for building richer web-facing forms, or AI assistants like Klai layered on top of the database for natural-language queries and automation. Both introduce a new wrinkle for access testing: they often talk to the underlying data through their own connection, which may or may not respect the same privilege sets as the native client.

If an AI tool inside FileMaker (such as Klai) is given a service account to fetch data for natural-language answers, that service account's privilege set effectively becomes the ceiling for what the AI can reveal — including in a chat response. A Sales Rep asking the AI "what's our total revenue this quarter" should get blocked or redirected exactly as if they'd tried to open the finance layout directly. The same logic applies to FmBetterforms: a web form built on top of FileMaker needs its own explicit test pass, because a beautifully designed public-facing form can accidentally expose an editable field that was locked down everywhere else.

The practical rule: any new interface layered on top of your FileMaker data — AI, web forms, APIs, mobile apps — needs its own entry in the role-permission matrix. Don't assume a rule enforced in one interface is automatically enforced in another.

What does a solid role-access test checklist look like?

Use this as a repeatable checklist before every release that touches permissions:

• Role-permission matrix exists and is up to date
• A dedicated test account exists for every role, not just Admin
• Every layout has been opened and reviewed under every relevant role
• Every portal and related-table view has been checked for leaked fields
• Every script has been reviewed for "run with full access" settings and what that bypasses
• Record-level rules (creator-only edits, department-only visibility, etc.) tested with two or more accounts in the same role
• Every external access channel (WebDirect, Go, API, AI assistant, custom forms) tested against the same matrix
• Role changes tested live (promote/demote a test user, confirm immediate effect)
• Results logged with pass/fail and date for audit purposes
• Re-test scheduled after any schema or script change, not just after a new feature

How often should you re-test role-based access?

Treat it like regression testing for business logic: any release that adds a field, a layout, a script, or a new integration touching existing tables should trigger at least a partial re-run of the matrix for the roles affected. A good rule of thumb from real projects: if the change touches a table that appears in more than one role's permission profile, re-test all of those roles — not just the one the feature was built for.

For a broader view of how this fits into keeping a custom system reliable over years of changes and multiple developers, see Loggix's guide on how to make custom business software reliable and transferable.

FAQ: quick answers on testing role-based access

Do I need a separate test account for every single role? Yes. Testing as Admin tells you almost nothing about what a restricted role actually experiences — permissions bugs are invisible from an account that can see everything.

Is layout-level testing enough, or do I need to test scripts too? Scripts too. A locked-down layout can still be reached indirectly through a button or script step that runs with elevated privileges.

What's the biggest blind spot teams have? External access points — APIs, AI tools, web forms — that read the same data through a different door and were never checked against the same rules as the main client.

Should permission testing be automated? Where possible, yes, especially for record-level rules that are easy to break silently. But even a simple manual matrix, reviewed on a schedule, catches the majority of real-world issues.

Getting role-based access right is less about clever configuration and more about disciplined, repeatable testing — the kind of habit that keeps a growing FileMaker system trustworthy as more people, roles, and tools connect to it. If your team is dealing with a system that's outgrown its original permission setup, or you're adding AI features, web forms, or API integrations that need to respect the same access rules as everything else, Loggix can help map out a testing approach and build the safeguards directly into the solution — whether that means tightening an existing FileMaker system, building a connected web application, or setting up integrations that carry the same access logic across every channel.