Setting Up User-Level Permissions in MS Access, Explained

Clients ask me about this constantly: "How do I stop the front desk from deleting invoices, but still let the accountant edit them?" Fair question. The problem is that the feature everyone remembers, Access User-Level Security, was quietly retired years ago. If you've found an old tutorial telling you to open the Workgroup Administrator and create a .mdw file, you're reading instructions for a version of Access that no longer works that way.

So let me walk you through what's actually possible in modern Access, and how my team handles permission control for real businesses in 2026.

The feature that's gone (and why)

User-Level Security (ULS) existed in the old .mdb format. It let you define user accounts, groups, and granular rights down to individual tables and forms. When Microsoft introduced the .accdb format back with Access 2007, they dropped ULS entirely. It was complicated, people locked themselves out of their own databases regularly, and it never really stopped a determined user.

If your database is still an .mdb file, ULS might technically function, but I'd never recommend building a business around it today. The format is dated, and you lose access to features you're probably already paying for.

There is no built-in, click-to-configure permission system in modern .accdb databases. Anyone telling you otherwise is describing software from fifteen years ago. Permission control in current Access is something you build, not something you switch on.

What "setting up user-level permissions in MS Access" means now

These days, controlling who can do what comes down to three practical layers. Most well-built databases use a combination of all three.

1. A users table and login form

This is the approach I use most often for standalone Access files. You create a hidden table listing each staff member, their password, and a role (say, Admin, Editor, or Viewer). A login form checks their credentials when they open the database, then stores their role in memory. From there, your forms and buttons behave differently depending on who logged in.

For example, the accountant's login enables the "Edit Invoice" and "Delete" buttons, while the front desk sees those buttons greyed out or hidden entirely. It's not bulletproof against someone who knows Access inside out, but for ordinary office staff it works reliably and keeps honest people honest.

2. Splitting the database and locking the back-end

If you haven't split your database into a front-end and back-end yet, that's step one for any multi-user setup. Each person gets their own copy of the front-end on their machine, and all the data lives in one shared back-end file on the server. I've written separately about how to do this, and it matters here because you can set Windows file permissions on the back-end folder.

That means you can let some people's Windows accounts open the data file while blocking others at the network level. It's a blunt instrument, but it's genuinely enforced by the operating system rather than by Access itself.

3. Windows folder permissions as the real gatekeeper

Here's the honest truth I give every client: the strongest access control for an Access file lives outside Access. If someone shouldn't touch the payroll database at all, don't rely on a login form. Put the file in a network folder that only certain Windows accounts can reach. Your IT person or I can configure this through standard folder security settings.

Comparing your options

Each method fits a different situation. Here's how I weigh them up when a client describes what they need.

When Access alone isn't enough

Sometimes the honest answer is that Access isn't the right place for the security you need. If you're handling medical records, detailed financial data, or you simply have too many people who shouldn't see each other's work, I'll usually suggest keeping Access as the friendly front-end and moving the actual data into SQL Server.

SQL Server has a genuine permission system: real user logins, read-only versus read-write rights, even column-level control. Your staff still open the same familiar Access forms, but the database decides what each person is allowed to pull up. It's the only way I'll set up something with true, enforceable, per-user security.

A practical path to get this working

If you want to add permission control to an existing Access database, here's the order I'd tackle it in:

1. Split the database into a front-end and back-end if it isn't already.
2. Put the back-end in a network folder and set Windows permissions so only the right people can reach it.
3. Add a users table with roles, plus a login form that identifies who's using the app.
4. Go through your forms and reports, hiding or disabling the buttons each role shouldn't use.
5. Decide whether your data is sensitive enough to justify moving the back-end to SQL Server.

You don't have to do all five at once. Even just steps one and two get most small offices to a far safer place than a single shared file sitting on someone's desktop with no restrictions at all.

A word on passwords

People often confuse a database password with user permissions. A single password on the file (the kind you set through Access encryption) means everyone who has it gets full access to everything. That's fine if your whole team is trusted equally, but it does nothing to separate roles. Permissions are about different people having different rights, which is a bigger job than one shared password.

Setting up user-level permissions in MS Access takes a bit of planning, but it's very doable once you know the real tools involved rather than chasing a feature that no longer exists. Most of this work is straightforward for an experienced hand, and my team typically handles existing-database jobs like this from $30/hour.

If you'd like help figuring out which approach suits your situation, or you want someone to set it all up properly, feel free to get in touch. I'm happy to look at your database and tell you honestly what it needs.