Translating permission sets, security filters and licensing into role-based security
How Business Central's object-level permission sets, security filters, entitlements and user groups map — and do not map — to D365's role/duty/privilege hierarchy, organisation access, segregation of duties, and security diagnostics.
What you will be able to do
Explain how BC permission sets (object type + object ID + operation) differ from D365 security roles with duties, privileges and entry points
Map BC security filters to D365 organisation access (legal entity, operating unit scoping)
Translate BC entitlement and plan-based licensing into D365 security-role assignment and licensing consumption
Design a segregation-of-duties model from BC process ownership rather than from BC permission-set rows
Identify security artifacts that retire versus those that inform target role design
Introduction
Business Central security is built around permission sets — named collections of object-level grants. A permission set says: "for this object type (table, page, codeunit, report) at this object number, grant these operations (Read, Insert, Modify, Delete, Execute)." Users receive permission sets directly or through user groups, and their…
BC security architecture: permission sets, entitlements and filters
Permission sets can be system-defined (shipped by Microsoft or an extension) or tenant-defined (created by an administrator). Modern BC also supports composable permission sets — a permission set that includes other permission sets by reference.
D365 security architecture: roles, duties, privileges and access
A single duty can participate in multiple roles (shared responsibility). A single privilege can participate in multiple duties. The model is designed for composability: rather than listing hundreds of object grants, you compose roles from meaningful business responsibilities.
Why row-level conversion is impossible
Consider a concrete BC permission: "Read/Insert/Modify on Table 39 (Purchase Line)." In D365, the ability to create a purchase order line is not controlled by a grant on a table. It is controlled by:
The redesign methodology: process roles from evidence
Rather than converting BC permission sets, the programme designs D365 security from process roles. The BC security estate provides evidence — not a template.
Security filters and their D365 alternatives
BC security filters restrict record visibility by field value. The programme must decide how each filter requirement is handled:
Licensing translation
BC and D365 use different licensing structures. The migration must produce a per-user licence classification based on target-system activities:
Custom permission sets: what to carry forward
The key principle: custom permission sets are evidence of business requirements. They are not importable artifacts. Each one must be interpreted — what business requirement does it serve? — then expressed through D365's richer security vocabulary.
Testing and diagnostics
Security role analysis — view effective access for a user across all roles, duties, and privileges. SoD violations report — list all users with conflicting duty assignments. Task recorder + security diagnostics — record a business process and identify which privileges are required to perform it.
Knowledge check
Summary
Business Central security grants object-level operations through permission sets. D365 security composes roles from duties and privileges that reference entry points and services. The addressing models are incompatible — no row-level conversion exists.