Dynamics 365 Business Central: User Management & Permissions (The Complete Admin Guide)

Why this matters

Good access control keeps your data safe, your auditors happy, and your users productive. Business Central (BC) gives you flexible building blocks—users, permission sets, user groups, and security filters—to implement least-privilege access without slowing the business down.

Quick glossary

User: A person (or app) authenticated via Microsoft Entra ID (Azure AD) who can sign in to BC.
Permission set: A named bundle of table/data permissions (Read, Insert, Modify, Delete, Execute). Comes from the system, Microsoft/ISV extensions, or your tenant.
User group: A reusable container of permission sets, assignable to many users at once (optionally scoped by company).
Security filter: A record-level filter (by table/field) attached to a permission set to limit which rows a user can see or change.
Entitlement: License-level rights the tenant inherits from your BC license; not editable by admins.
Profile (Role Center): UI layout and role experience—not security. Helpful for UX, but separate from permissions.

The building blocks (and where to find them)

Use Tell Me (Alt+Q) to jump to these pages:

Users – create/enable/disable users; set company-by-company defaults and time zones.
Permission Sets – create, copy, record, and maintain permissions.
User Groups – bundle permission sets; assign to users by company.
Effective Permissions – analyze a user’s final access across all sources.
Change Log – audit who changed what, where.
Sessions – see who’s currently connected and end stale sessions.

A secure, scalable setup in 7 steps

1) Prepare identity & licenses

Manage identities in Microsoft 365 / Entra ID. Enforce MFA with Conditional Access.
Assign appropriate Business Central licenses (e.g., Essentials, Premium, Team Members) before inviting users to BC.

2) Design roles before permissions

Map your organization into job roles (e.g., “AR Clerk”, “Sales Rep”, “Warehouse Picker”). For each role, list the tasks they must perform. This guides which objects (tables/reports/pages/codeunits) they need.

3) Start with Microsoft’s baseline sets, then refine

Use Microsoft’s delivered permission sets (and those added by apps) as a starting point.
Never give SUPER as a default. Reserve it for a tiny number of admins and use it temporarily for troubleshooting.

4) Build reusable User Groups

Create a User Group per role (e.g., “FIN-AP-CLERK”).
Add the relevant permission sets to the group.
If needed, assign different sets per company within the same group.
Add people to groups instead of assigning sets one-by-one.

5) Apply Security Filters for record-level limits

Add a security filter to a permission set (e.g., Table Customer, Field Salesperson Code = JS).
Use filters to limit by company, dimension values, locations, salespeople, etc.
Keep filters simple and indexed to avoid performance hits.

Tip: If you’re restricting company access, use a filter on the Company table or company-scoped permission sets/groups rather than ad hoc exceptions.

6) Create custom permission sets (safely)

Copy an existing set and trim it down, or
Use Record Permissions:
1. Create a new set, choose Start recording.
2. Perform the end-to-end task in a clean test user.
3. Stop recording, then review and remove over-grants (common with background lookups).
Name sets consistently (e.g., FIN_AP_INVOICE_POST, SALES_REP_READ).

7) Validate with Effective Permissions

Open Effective Permissions for a user to see final rights (from sets + groups + extensions + security filters).
Fix over-privilege before go-live.

Day-to-day operations

Onboard a new user (checklist)

Create user in Entra ID; assign BC license.
In BC Users, add the person (usually automatic on first sign-in).
Assign User Groups (role-based) and, only if necessary, extra permission sets.
If needed, set company-specific group memberships.
Apply security filters for territory/location/dimension scoping.
Test with Effective Permissions.
Share the right Profile (Role Center) for a clean UX.

Offboard securely

Block sign-in (Entra ID) and remove license.
In BC, Disable User and remove from user groups.
End sessions and review Change Log for final activities.

Temporary elevation

Add a temporary permission set (with an expiry noted in your ticket).
Remove immediately after the task; log the change.

Designing with least privilege (practical patterns)

Read-only finance viewer
Sets: General Ledger read; customer/vendor/bank read; reporting execute.
No posting, no journal modify.
Sales rep scoped to their accounts
Sets: Sales read/modify; order creation; shipment/return rights as needed.
Filter: Customer table by Salesperson Code = @UserSalesCode (or explicit values).
Warehouse picker for one site
Sets: Inventory pick/put-away; warehouse shipment.
Filter: Location Code = MAIN on item ledger/warehouse activity tables.
External accountant
Add to a dedicated user group; restrict to production only; prefer read/approve/post where required; enable MFA.

Environments & external access

Production vs. Sandbox: Keep strict separation. Use security groups to control who can access each environment.
Extensions/Apps: New apps may add permission sets. Review after each install/update.
APIs & automation: For non-interactive integrations, use a service principal (Entra app registration) and assign app user permissions in BC—do not share human accounts or disable MFA.

Auditing, compliance & monitoring

Change Log: Enable for critical tables/fields (vendors, bank accounts, posting setups, G/L entries). Balance coverage vs. performance/storage.
Permission changes: Keep changes behind tickets; export permission sets periodically to source control (AL objects) or Excel.
Sessions & login failures: Monitor Sessions and telemetry (if using Application Insights) for brute force or unusual activity.
Segregation of duties (SoD): Ensure no single role can create a vendor and approve/pay it, or create a sales order and post/ship without oversight. Use approvals to enforce process gates.

Security filters: dos & don’ts

Filter on stable keys (Company, Location Code, Salesperson Code, Global Dimension).
Keep filters simple (e.g., =MAIN or a short IN (…) list).

Don’t

Rely on complex, changing lists maintained by hand.
Assume filters apply to everything—some extension objects may need extra review.
Forget performance: wide filters on large tables can slow posting and reporting.

Common pitfalls (and how to avoid them)

Overusing SUPER → Create dedicated admin sets for specific admin tasks (e.g., “User Admin”, “Report Layout Admin”), and keep SUPER to a minimum.
Mixing UI and security → Profiles/Role Centers don’t secure data. Always back UX changes with permission sets.
One-off user tweaks → Prefer user groups. One-offs pile up and become unmanageable.
Forgetting company scoping → In multi-company tenants, be explicit about which company each group/set applies to.
No test user → Keep a non-admin test account to validate the real experience.

Governance model you can copy

Naming
- Permission sets: AREA_PROCESS_ACTION (e.g., FIN_AP_INVOICE_POST)
- User groups: DEPT_ROLE (e.g., SALES_REP)
Change control
- PRD changes require a ticket; test in sandbox first; record who approved.
Review cadence
- Quarterly access review with managers; remove dormant accounts; rotate elevated access.
Documentation
- Keep a living matrix of Role → User Group → Permission Sets → Security Filters.

Go-live checklist

All users in Entra ID with correct licenses & MFA
User groups cover every role; no lingering direct SUPER
Security filters validated with real data volumes
Effective Permissions reviewed for a sample of users per role
Change Log enabled for critical data
External integrations use app users (no shared accounts)
Sandbox restricted to builders/testers; production restricted to business users
Run a mock access review and fix findings

FAQ

Q: What’s the practical difference between permission sets and user groups?
A: Sets define what; groups define who gets which sets (optionally per company). Groups make maintenance scalable.

Q: How do I see what a user really has?
A: Use Effective Permissions—it resolves everything from sets, groups, extensions, and security filters.

Q: Should I build everything from scratch?
A: No. Start from delivered sets, then record & trim to least privilege.

Q: How do I restrict users to one company?
A: Assign permissions/group memberships only for that company and/or add a security filter on the Company table.

Q: Can I clone another user’s access?
A: Yes—copy their User Group memberships and any direct permission sets. Then review Effective Permissions.

Final thoughts

Treat permissions like code: design for roles, version them, review regularly, and test changes before production. With user groups, security filters, and Effective Permissions, Business Central gives you everything you need to implement least privilege without sacrificing agility.

Nasir Mahmood

Microsoft Dynamics Certified Consultant