Picture your Business Central go-live week. People are learning new screens, deadlines are looming, and every few minutes someone hits a wall: “Access Denied.” The fastest fix in the room is always the same one. Give them SUPER. Problem solved, for now.
That “for now” is the part that gets everyone. It rarely stays temporary.
The idea in one minute
Business Central’s SUPER permission set hands a user full access to everything: all data and all application objects your license covers. It’s meant for a small handful of true admins, not a shortcut for a frustrated project team. Handing it out to keep go-live moving feels harmless in the moment, but it quietly erases the whole point of having permission sets in the first place, which is making sure people can do their jobs and nothing more. The fix isn’t complicated. It just takes more patience up front than clicking one checkbox.
What a permission set actually is
Think of a permission set as a labeled bundle of “yes” and “no” answers to one question: can this person read, insert, change, delete, or run this specific thing in Business Central? A table, a page, a report, a process. Every user needs at least one permission set assigned before they can do anything at all. A well-built accounts payable permission set lets someone enter and post vendor invoices. It does not let that same person redesign the chart of accounts or delete a fiscal year. That’s the whole design: match access to the job, nothing more.
Why SUPER is different, and risky as a habit
SUPER isn’t just a big permission set. It’s the ceiling. Microsoft describes it as the ability to read, use, update, and delete all data and all application objects within your license scope. Business Central actually requires at least one user in every database to hold it, and the very first user created gets it automatically. That part makes sense: someone has to be able to set everything else up.
The trouble starts when SUPER stops being “the one admin account” and turns into “most of the finance team, because it’s easier.” At that point you’ve lost segregation of duties, the basic control that keeps one person from being able to create a vendor, approve their own invoice, and cut the payment, all without anyone else touching the process. You’ve also lost a simple answer to an audit question you will eventually get asked: who can delete a posted transaction, and why do they need to? If the honest answer is “everyone,” that’s not a comfortable spot to be in.
Why the slower path pays off
Building real, role-based permission sets takes longer up front. You have to sit down and think through what an accounts payable clerk needs versus a controller versus a warehouse lead, and that conversation eats into a go-live timeline that’s already tight. But every hour you spend there is an hour you don’t spend later untangling who has access to what, and why. ✅ Once people get used to having full access, walking it back feels like punishment, even when it was never supposed to be theirs long term.
How to actually move people off SUPER
You don’t have to solve this in one afternoon. A few steps that work:
- Pull a current list of everyone holding SUPER today and ask, honestly, why each of them still needs it.
- Use the Record Permissions feature to watch what a person actually does in a normal week, then build their permission set from that instead of guessing.
- Check the Effective Permissions page before you make changes, so you can see exactly what someone can touch today and compare it to what they’ll have tomorrow.
- Assign permission sets through security groups rather than user by user. It’s much easier to review a handful of groups than fifty individual assignments.
- Keep SUPER down to the smallest number of true administrators, and consider SUPER (DATA) for anyone who genuinely needs broad data access without the ability to change how the system itself is built.
💡 None of this has to happen in one afternoon, or even one week. Start with your highest-risk users, the ones touching payments and posting, and work outward from there.
Thank you for reading!
Last time, in post #3, we talked about Shortcut Dimensions: You Only Get Two, Choose Wisely. Next up in this series: Test It Before You Trust It: Why Sandbox Discipline Matters, where we’ll get into why testing changes in a real sandbox saves you from some very avoidable headaches.
Sources
Interested in learning more? Below are some of my latest posts:
Leave a Reply