What shipped in Update 28.2
Update 28.2, part of Business Central's 2026 release wave 1, became generally available on June 14, 2026. Alongside new APIs for approval workflow analysis, PDF report retrieval, and sustainability data, Microsoft added a set of Business Central permission APIs built specifically for auditors and IT staff. In Microsoft's own words, the goal is to let organizations run "external auditing and analytics without compromising system integrity," with data flowing into tools like Power BI and Microsoft Copilot Studio.
This followed the Permissions Overview page that shipped earlier in the same release wave, in public preview from March 6, 2026, which gave admins a single screen to see permission sets, security groups, and user assignments across every installed app and extension. The APIs are the automatable, reportable version of that same idea, and together they're the biggest step up in Business Central permission visibility since the platform moved to security groups.
The five APIs, plain English
Every one of the new APIs is read only. Nothing you query through them can change a user's access, which is a deliberate choice: Microsoft wants auditors pulling data, not IT staff worrying that a report query could touch production permissions.
| API | What it exposes |
|---|---|
| Expanded permission sets | The full, resolved set of object level permissions inside a permission set, including anything pulled in from included sets |
| Access controls | Which users and security groups map to which permission sets across the tenant |
| Users permissions | Per user permission assignments, useful for answering what one specific person can do |
| User permission sets | The relationship between individual users, security groups, and the permission sets attached to each |
| Aggregate permission sets | Summary level metadata about permission sets themselves, across apps and extensions |
Together, they let you build a Power BI report or a Copilot Studio agent that answers questions like "who has access to the vendor bank account fields" or "which security groups can post to a closed period," pulled from live tenant data instead of a spreadsheet someone exported two months ago.
What native permission visibility still can't do
This is the part that gets lost when a release note gets summarized into a headline. Query access to permission data is not the same as managing, enforcing, or monitoring that access. Three gaps matter for anyone running Business Central under real audit pressure.
No continuous alerting
The APIs are pull based. You query them and get a snapshot, accurate at the moment you asked. Nothing in Update 28.2 pushes a notification when a user is added to a sensitive security group at 11pm on a Friday, or when someone's effective access suddenly widens after a permission set change. That gap is exactly what Business Central continuous monitoring tools are for. 2-Controlware's Continuous Monitoring module, a separate module on top of Authorization Box, works the other way around: you pick which permissions count as critical and subscribe to alerts on a dashboard and by email, with a frequency of immediate, daily, weekly or monthly, set up per database connection.
No field level enforcement
All five APIs work at the object and permission set level. Business Central's native permission model authorizes at the table level: if you can edit the Customer table, you can edit every field on it, including the ones an auditor flags first, like credit limits or bank details. The new APIs will tell you who has table level access. They won't stop one user from editing a customer's name while blocking another from touching payment terms. That's a different layer, the one field level security Business Central tools are built for, and it's what 2-Controlware's Field Security app does: it extends permission sets down to individual fields, table sections and actions, with a "Default Editable" allow list mode, so a field is locked unless a rule explicitly opens it. Rules need a linked permission set, and the app covers standard Business Central pages out of the box; a custom page needs an event subscriber to be covered too.
No segregation of duties conflict detection
Access controls and user permission sets tell you what one person can do. They don't cross reference that against a conflict matrix to flag that the same person can create a vendor, approve it, and pay it. Authorization Monitoring, the analysis module inside Authorization Box, runs that segregation of duties Business Central conflict analysis and reports the results by organization role, which is the correlation step auditors actually ask for.
Why this matters more at audit time than at release time
Most people who read a Microsoft release plan skim it once and move on. This one is worth a second look if your organization is heading into a SOX walkthrough, an ISAE 3402 engagement, or just an internal control review this year, because "can you show me who has access to X" is the single most common opening question in that room. Until now the honest answer for a lot of Business Central shops was a manual export, cross referenced by hand, and hoped to be current.
The new permission APIs make that answer faster and more defensible: pull live data instead of a stale spreadsheet, and hand the auditor a report instead of a promise. That's a real, immediate win, and it's worth telling your auditor about even if nothing else in your setup changes this quarter. It's also worth being precise with them about what changed: the underlying access model, the alerting, and the conflict rules did not move. Only the reporting did.
Where this leaves you
None of this makes the Update 28.2 APIs a bad addition, and it's worth saying plainly: Microsoft investing in read-only permission APIs for Business Central is a good sign, not a threat to plan against. It raises the baseline for everyone building on the platform. But raising visibility and closing actual risk are two different jobs, and the new APIs are squarely a visibility tool. Treat them as a better, faster data source for the reporting you already do, and keep the monitoring, field level enforcement, and conflict detection layered on top with tools built for that job.
If you're starting from zero, the free Advanced Permissions Recorder is a reasonable first step: it records which permissions a given task actually needs, useful groundwork before you tighten anything else.
A checklist for this quarter
- Confirm Update 28.2 is applied if you're on 2026 release wave 1, so the permission APIs are actually available to query.
- Use the new APIs for what they're good at: a fast, current export of who has what, solid evidence for an auditor asking for a permissions snapshot.
- Don't mistake a snapshot for monitoring. If you need to know the moment a sensitive permission changes, that still needs a tool built for continuous monitoring, not a report someone remembers to pull.
- If field level exposure is a live concern, bank details, payment terms, margin data, check today whether it's actually covered by field level security. Table level access alone will pass a permission audit and still leave that data exposed.
- Ask whether anyone has actually run a segregation of duties conflict analysis this year, or whether the org chart just looks reasonable on paper.
Related reading
- Streamlining Business Central permission sets: best practices
- Business Central permission sets and access control
- What is segregation of duties in D365?
- Unlocking the power of permissions with the Field Security app
- How do I gain control over my authorization setup?
