How to structure privilege sets in FileMaker

Most FileMaker security problems don't start with a hacker — they start with a well-meaning admin who clicked "Full Access" for a temp employee three years ago and forgot to change it back. Or a developer who created one privilege set per employee instead of per role, so now there are 40 privilege sets for 25 users and nobody remembers which one does what. If you've ever opened Manage > Security and felt a small wave of dread, this article is for you.

We'll walk through how to design a privilege set structure that scales, how to avoid the most common mistakes, and how to audit an existing solution that's already gotten messy.

What exactly is a privilege set, and why does the structure matter?

A privilege set in FileMaker is a named bundle of permissions: which layouts a user can see, which records they can create, edit, or delete, which value lists they can access, which scripts they're allowed to run, and what level of access they have to data, layouts, and value lists on a table-by-table basis.

The structure matters because privilege sets are usually the only thing standing between an accounting clerk and the ability to delete last year's invoices, or between a warehouse picker and the customer's margin data. A flat, ad-hoc set of privilege sets might work fine with five users. At twenty users, three departments, and an external accountant who needs read-only access once a month, an unstructured approach turns into either a security hole or a support ticket factory — usually both.

There's also a performance and maintenance angle that's easy to miss: every time you add a new field, a new layout, or a new script, you have to remember to update every privilege set that should touch it. With ten role-based privilege sets, that's ten checks. With forty person-based ones, it's forty — and it's the kind of tedious work that gets skipped under deadline pressure, which is exactly how permission drift happens.

Should you build privilege sets around roles or around individual people?

Always roles, never people. This is the single biggest structural decision, and getting it wrong is what causes most of the mess we see when we're called in to review an existing FileMaker system.

Here's the difference in practice:

• Person-based (avoid this): "Maria," "John_Sales," "TempWarehouse_March." Every new hire means a new privilege set, copied from a similar one and tweaked. Nobody remembers what was tweaked. When Maria moves from sales to finance, her old privilege set silently keeps its old permissions.
• Role-based (do this): "Sales Rep," "Sales Manager," "Warehouse Staff," "Finance," "External Accountant (Read-Only)." When Maria moves to finance, you simply reassign her account from "Sales Rep" to "Finance." Nothing else changes, and there's no ambiguity about what she can now access.

A useful rule of thumb: if you can't describe a privilege set in one short phrase that would make sense to a non-technical manager ("what a warehouse picker needs to do their job"), it's probably too specific or too broad.

How many privilege sets should a typical FileMaker system actually have?

There's no universal number, but most well-structured solutions land somewhere between 5 and 12 privilege sets, even for organizations with 50+ users. If you're seeing 30+ privilege sets for fewer than 30 users, that's a strong signal the structure has drifted into person-based territory and needs a cleanup.

A typical layered structure looks like this:

1. [Full Access] — reserved for developers and system admins only, ideally 1-2 accounts, never used for daily work.
2. Manager / Supervisor — broad read/write access within their department, some delete rights, access to reports.
3. Standard Staff (per department) — Sales, Warehouse, Finance, Support — each scoped to what that department actually touches.
4. Read-Only / Reporting — for auditors, external accountants, or executives who need visibility without edit rights.
5. Integration / API accounts — a dedicated privilege set for accounts used by connectors, scripts, or an API integration, scoped as narrowly as possible to only what that integration needs to read or write.

That last one is worth pausing on. We regularly see integration accounts running under Full Access "because it was easier to set up." That's a real risk: if the API key or script is ever compromised, the attacker inherits full access to the entire system, not just the order table it was supposed to touch.

What's the difference between privilege sets, extended privileges, and accounts?

This trio confuses a lot of people new to FileMaker security, so it's worth being precise:

• Accounts are login credentials — the username/password (or external authentication) a person or system uses to get in.
• Privilege sets define what an account is allowed to do once inside — records, layouts, scripts, value lists, custom menus, data access via ODBC/OSGi, etc.
• Extended privileges are named permissions attached to a privilege set that control access to specific channels — for example, whether that privilege set can connect via FileMaker WebDirect, via the Data API, via ODBC/JDBC, or run particular scheduled scripts on the server.

An account has exactly one privilege set. A privilege set can have multiple extended privileges attached. Get this relationship backwards and you'll spend hours debugging why a user "has the right privilege set but still can't log in via WebDirect" — the answer is almost always a missing extended privilege.

How do you set field-level and record-level security without breaking usability?

FileMaker lets you go granular — down to individual fields and individual records — but granular doesn't mean you should use every knob available.

Field-level security is worth using for genuinely sensitive fields: salary data, cost price versus sell price, personal identification numbers, internal notes. Set these to "limited" access via a calculation rather than hiding them purely with layout tricks — layout-only hiding can still be bypassed through Find mode, exports, or scripts.

Record-level security (via calculated access on the privilege set, e.g. "only records where CreatedBy = Get(AccountName)") is powerful for scenarios like:

• Sales reps who should only see their own customers' records, not the whole company's.
• Branch offices that should each see only their own location's data.
• HR records that only specific managers should access.

The gotcha: record-level restrictions run as a calculation on every record fetch, so on very large tables this can measurably affect find and sort performance if the calculation is complex or unindexed. If you're already dealing with a solution that feels sluggish, it's worth checking whether record-level security calculations are part of the cause — this ties directly into the broader question of how to improve the performance and structure of a FileMaker solution.

What are the most common privilege set mistakes we see in real FileMaker systems?

1. Everyone gets Full Access "temporarily" and it never gets revoked. This is the single most common finding during a security review. Track down every account with Full Access and ask, out loud, why each one needs it.
2. One privilege set per person instead of per role. Covered above — leads to permission drift and confusion at scale.
3. Integration and API accounts sharing a privilege set with human users. If a connector account and a manager account share a privilege set, tightening security for one affects the other unpredictably.
4. No read-only tier. Auditors, accountants, or executives end up with full edit rights just because nobody built a lighter option, creating unnecessary risk of accidental changes.
5. Layout-only security instead of real data security. Hiding a button doesn't stop someone from finding the record through a different layout or a script.
6. Privilege sets never reviewed after go-live. A structure that made sense for 8 users rarely still fits at 40 users and three new integrations later — yet it's rarely revisited unless something breaks.
7. No documentation of what each privilege set is for. Six months later, even the original developer can't confidently say what "Custom_2" does.

How do you audit and clean up an existing, messy privilege set structure?

If you've inherited a FileMaker system with years of ad-hoc privilege set changes, here's a practical cleanup sequence:

1. Export the current list. Go through Manage > Security and list every privilege set, every account, and which privilege set each account uses.
2. Group accounts by actual job function, not by what they're currently assigned. You'll usually find several accounts doing the same job under different privilege sets.
3. Identify every Full Access account and confirm, with the business owner, that each one truly needs it.
4. Design the target role list (5-12 roles, as above) based on real job functions, including a read-only tier and a dedicated integration tier.
5. Build the new privilege sets in parallel, without deleting the old ones yet, and test each one with a real test account per role.
6. Migrate accounts one at a time, verifying access after each move rather than doing a mass cutover.
7. Decommission the old privilege sets only after a full work cycle (a week or a month, depending on how the business uses the system) has passed with no access issues reported.
8. Document the final structure — one paragraph per privilege set describing who it's for and what it grants — so the next developer or the next audit doesn't start from zero.

Does adding AI or automation change how you should structure privileges?

Yes, and it's an area many teams overlook. As FileMaker solutions increasingly connect to AI tools — for example, a script that sends record data to an AI service for summarization, classification, or drafting — that connection needs its own scoped privilege set, just like any other integration.

An AI-assisted script that reads customer support tickets to draft suggested replies doesn't need delete rights to the invoices table, and it definitely shouldn't run under a Full Access service account just because that was the fastest way to get it working during a proof of concept. Treat every automated or AI-driven process exactly like the API integration case above: give it the narrowest privilege set that lets it do its specific job, and log what it accesses.

Quick checklist: is your privilege set structure healthy?

• Privilege sets are named after roles, not people.
• Fewer than ~12 privilege sets for most organizations, regardless of headcount.
• No more than 1-2 accounts with Full Access, none used for daily work.
• At least one read-only privilege set exists for auditors/executives.
• Every integration, connector, and AI process has its own scoped privilege set.
• Sensitive fields (salary, cost price, personal data) use field-level access, not just layout hiding.
• Record-level security calculations are indexed or kept simple enough not to hurt performance.
• Each privilege set is documented in one sentence describing who it's for.
• Privilege sets are reviewed at least once a year, or after any major headcount or integration change.

FAQ: common questions about FileMaker privilege sets

Can a user belong to more than one privilege set at once? No — each account is tied to exactly one privilege set at a time. If someone genuinely needs a mix of permissions from two roles, that's usually a sign you need a third, more specific privilege set rather than trying to combine two.

Should developers work under their own named account or a shared "Developer" account? Each developer should have their own named Full Access account. Shared credentials make it impossible to trace who changed what, which becomes a real problem the first time something breaks in production.

Does WebDirect or the Data API need separate privilege set planning? Yes. Access through WebDirect, the Data API, ODBC/JDBC, and scheduled server scripts is controlled by extended privileges attached to a privilege set — so any account using these channels needs to be checked for the right extended privileges, not just the right base permissions.

How often should privilege sets be reviewed? At minimum once a year, and additionally whenever there's a significant change: a new department, a new integration, an employee departure, or a merger/acquisition that brings new users into the system.

Getting privilege sets right is rarely about adding more security features — it's about designing a structure simple enough that the people maintaining it can actually keep it correct over time. If your FileMaker solution has grown organically and you're no longer sure who can access what, or you're planning new integrations, an ERP connection, or AI-driven scripts that need their own carefully scoped access, Loggix can help map out a privilege set structure — and the broader system architecture around it — that holds up as your organization keeps growing.