User and Permission Management

Purpose

This page explains the core principles of user and permission management in Microsoft Dynamics 365 Business Central. It helps you set up new users so that sign-in, data access, interface, and business responsibilities work together cleanly from the beginning. It also shows where permissions can be adopted from the standard setup, extended in a controlled way, or adapted to groups of users.

Prerequisites

• The user exists in Microsoft 365 or Microsoft Entra ID.
• The user is available in Business Central or can be imported from Microsoft 365.
• The setup is performed by a user with sufficient rights, for example IT or a key user.

Recommended Sequence

1. Check the user or import the user from Microsoft 365.
2. Assign the required permission sets.
3. Use security groups for recurring roles.
4. Add business-specific settings in User Setup.
5. If required, maintain warehouse assignment and profile.
6. Review the effective permissions before productive use.

Setup Components

Users

Open the Users page and check whether the required user already exists. In the cloud version, sign-in is handled through Microsoft 365, so separate password maintenance in Business Central is usually not required.

Permission Sets

Permission sets control which data a user can view, create, change, or process. Open the user card and assign the required permission sets there.

Rights are assigned based on system objects and actions. In practice, this usually distinguishes between read, insert, modify, delete, and execute permissions. This makes it possible to control very precisely what a user can actually do in a given area.

Typical starting points are:

Multiple permission sets can be combined. This is often more transparent and easier to maintain than one single oversized permission set.

If the existing standard sets are not sufficient, you can define your own permission sets. A practical method is permission recording: start the recording, perform the required business steps, and save the result as a new permission set. This often allows you to model business requirements precisely without development effort.

Security Groups

If multiple users have the same tasks, permission assignment should be handled through security groups whenever possible. This lets you manage rights centrally and reduces manual individual assignments.

The typical procedure is:

1. Open Permission Set by Security Group.
2. Assign the matching permission sets to the security group.
3. Manage user membership in Microsoft 365.

Depending on the Business Central version, deployment model, and product context, group management can differ in detail. If security groups are not available in the required form in your environment, assign the permission sets directly on the user level instead.

User Setup

The User Setup page complements the pure rights assignment with business restrictions and default values. It does not replace permission sets, but refines the user’s working context.

Warehouse Assignment

For warehouse processes, a permission set alone is not always enough. If a user should process warehouse activities, the user must also be assigned on the Warehouse Employees page to one or more locations.

At minimum, maintain the user ID and the location code. You can also define a default location if needed.

Profiles and Personalization

A profile controls the interface, especially the role center, navigation, and visible actions. Maintain the appropriate profile in User Settings in the Profile ID field.

You can also define in the profile whether personalization is allowed. If Disable personalization is enabled, the user cannot make personal interface changes.

If personalization is allowed, users can adapt lists, FactBoxes, tiles, or other interface elements to their own working style. This flexibility is useful in daily work, but it should be controlled consciously when a consistent user experience is required.

When administrators reset or remove personalized pages, the changes usually take full effect only after the user signs in again. This is especially relevant when interface issues are caused by user-specific changes.