How Acumatica's screen-level access rights, user roles, restriction groups and branch access map onto D365's bottom-up role → duty → privilege → entry point model, Extensible Data Security and native segregation of duties — and why the closest-looking source model in the library is the one most likely to be translated too literally.
Of every source system in this library, Acumatica's security model is the one that looks most like the target. That is genuinely good news, and it is also the reason this chapter spends its first two sections warning about it.
The two blank cells are the whole story of this chapter. Acumatica has a two-layer model — role, then access right against a screen — and D365 has a four-layer model. The extra layers exist for one reason: so that a capability can be defined once and reused in many roles.
This is worth stating positively, because it is a real advantage and Acumatica programmes should use it.
Acumatica: role → access right → screen. D365: role → duty → privilege → entry point.
Acumatica's row-level mechanism is the restriction group. It exists for exactly the case the target's mechanism exists for: a user has access to a form, but on that form should see one set of entities and not another.
This is where the security domain becomes dependent on the organisational one, and where a literal translation does lasting damage.
Acumatica has no segregation-of-duties rules engine in the sense D365 means. Separation of concerns in the source is achieved by not granting conflicting access rights to the same role, which works and which leaves nothing behind to migrate — there is no conflict catalogue, no severity scale and no override log.
Whatever the commercial arrangement in a given source estate, generosity in access design there does not produce a per-user price signal. That absence is why broad roles, generous access levels and a long tail of generic inquiries accumulate without anybody objecting on cost grounds.
Database log is opt-in and narrow by design. It is configured per table and per field and is explicitly not intended for high-volume transactional tables. Enabling it broadly to feel safe produces a log table that grows faster than anyone plans for, with a measurable performance cost on every write to the logged table.
Export access rights by role, and treat it as an inventory rather than a design. It is unusually reliable and it is not the answer. Set it aside for step 8. Enumerate every explicit revocation. These are the entries with no target equivalent.
Take an accounts payable specialist in a two-branch estate. In the source they hold one role with access rights across several forms, one right explicitly revoked, a restriction group limiting which vendors they see, branch access to one of the two branches, and two generic inquiries they use daily.
Acumatica's screen-level access-rights model is the closest structural analogue to D365's entry-point model in this library, and that is a genuine head start: the securable object is the runnable unit on both sides, access level belongs to the grant on both sides, and an access-rights export is a reliable statement of what is granted…