How NetSuite's single-role-at-a-time permission model, Subsidiary and segment restrictions, and largely manual segregation-of-duties review translate into D365 F&O's additive role-duty-privilege-entry point hierarchy, Extensible Data Security policies and configurable SoD rules — and why role design now drives both compliance posture and licence cost.
Part 1 settled where the organisation lives — which Subsidiary becomes which legal entity, which segment becomes which financial dimension. This chapter settles who is allowed to touch it, and the two platforms answer that question completely differently.
The word "bottom-up" is not decoration: a privilege cannot reference an entry point absent from the running application — a developer drags real menu items into a privilege definition. Security artefacts are generated from what the application exposes, not declared independently.
NetSuite's login-time role dropdown means a user holding both "A/P Clerk" and "A/P Manager" has only one role's permissions live at any moment — whichever was selected that session.
D365 splits this into two tools. Legal-entity scoping of a role assignment — set on the Assign users to roles page — is the coarse, no-code equivalent of a Subsidiary restriction, and the first tool to reach for.
NetSuite has no native segregation-of-duties rule engine. Compliance-conscious organisations manage the risk through careful role design reviewed by a controller or auditor at build time, periodic manual access reviews built from role-assignment exports, and, in more regulated shops, a third-party GRC SuiteApp bolted on for automated…
D365's named-user licensing model derives the required licence from which entry points — and at what access level — a user's duties and privileges can reach. Full application licences (Finance, Supply Chain Management, Commerce, Human Resources, Project Operations) sit alongside lighter tiers: Team Members, plus Operations – Activity…
NetSuite's System Notes subtab is automatic, unconfigured and on by default for most record types, capturing field-level old-value, new-value, user and timestamp detail for UI, CSV import and most script changes, alongside a separate Login Audit Trail for sign-in history.
Start from the business process map — procure-to-pay, order-to-cash, record-to-report — not the NetSuite role list. List the tasks each process requires. For each task, identify the minimum entry points and access levels needed, and group them into a duty named after the task, not the legacy role.
D365's role, duty, privilege and entry point hierarchy is generated bottom-up from the entry points the application exposes, and it is genuinely more granular and administratively demanding than NetSuite's flat, permission-and-restriction model.