Security groups, menu security and field security translated into the role, duty, privilege and entry-point model

How Epicor's security groups, Menu Maintenance, field/method security and process security map onto D365's role → duty → privilege → entry-point hierarchy, Extensible Data Security and native segregation of duties — and the licensing and auditing consequences of getting role design wrong.

What you will be able to do

• Explain why D365's role → duty → privilege → entry-point hierarchy is built bottom-up rather than declared top-down
• Map Epicor security groups and menu security onto D365 security roles, duties and privileges
• Describe how Epicor field and method security translate to entry-point access levels and Extensible Data Security
• Configure a segregation-of-duties rule and explain honestly what D365 provides natively versus what requires additional tooling
• Predict how a role's entry points drive its Finance, SCM, Team Member or Activity licence requirement
• Identify the Task Agent / scheduled-process identity question and its D365 batch-framework equivalent

Introduction

Part 1 of this domain mapped the skeleton — legal entities, sites, warehouses, financial dimensions, and the operating-model decision. This chapter is about who is allowed to touch that skeleton, and how you prove it.

The D365 security hierarchy: built bottom-up from the entry point

D365 security composes four levels above the entry points they secure. Unlike Epicor — where an administrator assigns a security group and configures which menu items that group can see — the D365 hierarchy is generated from the bottom up, starting from objects that already exist in the application.

Epicor security constructs, mapped

An Epicor security group is the primary container a user is assigned to. It determines menu access, field-level access, and method-level access. In D365, the nearest equivalent is a security role — the object a user receives. The structural difference is depth: a D365 role never carries permissions directly;

Role assignment and legal-entity scope

In Epicor, a user is assigned to a security group within a Company. The Company boundary naturally limits what the user can access.

Segregation of duties: real but light

Epicor has no native segregation-of-duties engine. Separation of conflicting functions is achieved through security-group design (not granting conflicting menu items to the same group) or through BPM-enforced approval workflows. There is no system-level check that alerts when a conflicting combination is granted.

Licensing: how role design becomes a cost model

Every entry point a role can reach carries a licence-entitlement tag against the D365 subscription tiers — Finance, Supply Chain Management, Commerce, Human Resources, Team Members, and Activity — at the access level (Read or Write) the role grants.

Auditing and change tracking

D365's native audit surface is narrower than what an Epicor team typically expects if they have relied on database triggers, UD-field logging, or BPM-based audit trails.

The Task Agent identity question

Epicor's Task Agent runs scheduled background processes — MRP regeneration, SSRS report bursts, data imports — under a configured system identity. The security profile of that identity determines what the Task Agent can access.

A practical role-design method for the migration

The most common mistake is starting from the Epicor security-group export. That export describes groups shaped by years of menu-centric accretion — one-off menu additions, legacy customisations nobody cleaned up — and porting that shape produces a D365 role set with all of Epicor's accumulated complexity and none of D365's…

Knowledge check

Summary

D365 replaces Epicor's menu-gated, field-gated security model with a bottom-up hierarchy — entry point, permission, privilege, duty, role — generated from what the application already exposes rather than declared from a menu tree. Field-level security has no per-field equivalent; row-level security moves to XDS;