How GP's operation → task → role hierarchy, per-company user security, field level security, account level security and the POWERUSER habit map onto D365's role → duty → privilege → entry point model, Extensible Data Security and native segregation of duties — and why role design in the target writes the licence bill.
Most chapters in this path are about moving a GP concept into a differently shaped target concept. This one is about something slightly harder: moving a GP habit into a target that will not tolerate it.
D365 security has four layers, and the direction of travel matters more than the layer count. The application ships with securable objects already in place; privileges are generated or authored against them; duties group privileges; roles group duties. Nothing above the entry point can be designed without knowing what sits below it.
GP's model is documented as Operation → Task → Role → User: an operation is the base level element of security for windows, for reports, for posting permissions and for document access; a task is a group of operations for one business task; a role is a group of tasks defining a job; and a user can hold many roles.
GP security is company-specific: the roles assigned to each user are set per company, and the security records live inside each company database. A user with access to five companies has five independent grants.
D365's row-level restriction mechanism is Extensible Data Security. A policy is built from a small number of parts, and it is worth seeing the shape before deciding whether a GP requirement needs one.
GP has no segregation-of-duties engine. There is no ruleset to export, no conflict catalogue to translate, and no organisational habit of thinking in conflicting-duty pairs.
This is the section that changes behaviour, and it is the one GP administrators have least preparation for.
GP administrators arrive with a mixed set of expectations here, because GP's audit story is itself mixed — some of it in the application, some of it in SQL Server, some of it in the fact that the team is small enough to notice.
Inventory business processes, not security records. Start from what the business does — receive an invoice, approve it, pay it, reconcile the bank — and produce a list of recognisable business-process chunks. These become candidate duties. Doing this first is what stops the GP export from becoming the design.
Take a GP accounts payable clerk in a three-company estate. In GP, the clerk holds one role in the operating company and a narrower one in the shared-services company, and the role is assembled from tasks that group operations across the Purchasing series.
GP and D365 F&O both organise security in layers, both use the word "role" for the object a user receives, and both inventory permissions from what the application actually exposes rather than from a written matrix. Those similarities make the mapping approachable.