Business Central permissions, driven by your Azure AD groups

Managing user permissions in Business Central is one of those jobs that starts simple and quietly becomes a problem. You add the right permission sets when a user joins, you remember to remove them when they leave, and somewhere in between a starters-and-leavers tracker grows in a spreadsheet and someone's contractor access sits open for two months after the project ended.

Most organisations already have a cleaner answer sitting in Microsoft Entra ID. They just haven't connected it to Business Central yet.

The groups you already manage

If your team uses Microsoft 365, you almost certainly have Azure Active Directory security groups. There's one for the finance team, probably one for AP processors, one for anyone with read-only access to accounts. Those groups drive access to SharePoint folders, Teams channels, and shared inboxes. They're maintained by IT or HR as part of the onboarding and offboarding process.

Business Central has its own permission system — permission sets that grant access to tables, pages and reports. Managing those is a separate job, usually owned by a BC admin, and it runs in parallel with AD group management rather than alongside it. When someone changes role, two separate people need to act. When someone leaves, if either misses it, access persists.

The gap between these two systems is where permission drift lives.

What BC already knows about your AD groups

Business Central has a built-in Microsoft Entra integration. When you register an Azure AD security group in BC's Microsoft Entra Groups setup, BC creates a corresponding User Group and keeps its membership in sync as users log in. This isn't a third-party feature — it's standard BC behaviour that comes with every Business Central licence.

Most BC customers have this set up for the purposes of licence assignment. Fewer use it as the foundation for permission management.

Closing the loop automatically

The missing piece is the mapping: which Azure AD group should grant which Business Central permission sets, and in which companies? That's what Amplio Smart Permissions adds.

You define the mapping once — AD group A gets these permission sets in Company X, AD group B gets a different set in Companies X and Y — and Smart Permissions takes it from there. When a user logs in, it reads their current AD group membership (via BC's Entra integration, not a direct Graph call) and applies the mapped permission sets. An hourly scheduled sync catches anyone whose membership changed between logins.

The practical effect: IT adds someone to the BC Finance Team group in Azure AD. On their next Business Central login, the right permission sets are there. No BC admin action required.

What changes when you run this way

The most immediate change is onboarding. A new hire needs to be added to the right AD group — which IT is doing anyway for Teams and SharePoint access — and BC permissions follow automatically. There's no separate "set up the BC user" step for the finance manager to remember.

Offboarding is cleaner too. Removing someone from an AD group removes their BC permissions on the next sync pass, without anyone logging into Business Central to do it manually.

Role changes work the same way. A user moving from AP processing to financial planning gets added to one group and removed from another in Entra ID. The next BC login reflects the new role. The starters-and-leavers spreadsheet becomes redundant.

For organisations with multiple BC companies, the mapping is per-company: you can give the same AD group different permission sets in your UK entity versus your holding company, with no need for manual per-company setup for each user.

What it is not

Smart Permissions does not replace BC's native permission set architecture — it routes users into it automatically. You still define what each permission set grants. You still control which AD groups exist and who is in them. The extension is the bridge between those two systems, not a replacement for either.

It also does not call Microsoft Graph directly. All AD group data comes through BC's standard Entra integration, which means the extension works within your existing Entra consent model and does not require any additional API permissions or app registrations.

Who this is for

If your organisation has more than fifteen Business Central users and you're managing permissions by hand, the mismatch between AD group management and BC access control is already a source of friction. The larger your team and the more frequently roles change, the more that friction compounds.

If you already use Azure AD groups to manage access to other Microsoft services — and almost every Microsoft 365 customer does — the groups you need are already defined. You're not building new infrastructure; you're connecting what you have.

The product page for Amplio Smart Permissions covers the setup steps, role structure and what the Permission Sync Log shows during and after a sync run. If you'd like to talk through whether it fits your BC setup, a free BC review is a good starting point.