Access Levels per Module
An access level decides what a user may do through the MCP Guard extension's own API pages in Microsoft Dynamics 365 Business Central. Two users with the same Business Central permissions can get different rights: a planner changes the plan, the others only read it. You set the level per module on the user's rule on the MCP Guard User Settings page. A user without a rule gets Read.
The modules
| Field on the rule | Covers |
|---|---|
| Production Access | productionOrders, prodOrderLines, prodOrderRoutingLines |
| Planning Access | planningLines, and the actions calculatePlan and calculateCalendar |
| Assembly Access | assemblyOrders, assemblyLines |
| Project Access | projectTasks, projectPlanningLines |
The levels
| Level | Allows |
|---|---|
| Read | Reading. This is the lowest level, and what a user without a rule gets. |
| Modify | Also changing existing records. |
| Create and Actions | Also creating records, deleting a production order, and the actions: refresh, refreshForward, release, reopen, calculatePlan, calculateCalendar. |
| Posting | Also posting an assembly order. For production, planning and projects it equals Create and Actions. |
Each level includes the ones before it. Posting is the only level that may post an assembly order. Create and Actions is the level that may delete a production order. See Production API.
How the level is decided
The same rule decides as for the companies and the MCP configuration: the line for the user, else the line of a security group the user is a member of with the lowest Priority. A new rule starts at Read for every module. When Microsoft Entra ID cannot be asked for the group membership, no group rule applies, so the user reads only.
Business Central enforces the level
The check happens in the API pages themselves, on every create, change, delete and action. It does not matter which MCP client or which MCP configuration the user connects with. When the rule grants less than the operation needs, Business Central refuses with a message like this one:
Your MCP Guard rule gives you Read access to Production, and this needs Modify. Ask your administrator to change the rule on the MCP Guard User Settings page.
The message names the level the rule grants, the module, and the level the operation needs.
It is a second check, not a replacement
The access level comes on top of everything Business Central already checks.
- The user still needs Business Central's own permissions on the data, for example on production orders.
- The user still needs the permission set MCP GUARD - USER. Since version 1.13.0.0 it holds every module page, so the level on the rule is what decides per module. See Permission Sets.
- The MCP configuration must still expose the operation.
The access level per module only covers the extension's own API pages. Microsoft's own API pages, such as sales orders and items, are not affected. Limit those with permission sets, the MCP configuration and the rule's General Access, which the BC MCP Pro connector applies. See General Access.
What the MCP client sees
The mcpUserSettings API page returns productionAccess, planningAccess, assemblyAccess, projectAccess and generalAccess for the signed-in user. A connector can use these values to hide the tools the user may not use. The BC MCP Pro connector does this: a tool or action that the rule does not allow is left out of the tool list. See Connect with the BC MCP Pro Connector.