How SYSPRO's operator-centred security, its Role Management settings templates, its operator/group/role/company precedence and its eSignature controls map onto D365's bottom-up role → duty → privilege → entry point model, Extensible Data Security and native segregation of duties — and why the target has no deny and no precedence.
This chapter has to be honest about two things at once: what SYSPRO's security model does, and how much of it can be established from evidence before a discovery workshop.
D365 security has four layers, and the direction of travel matters more than the layer count.
The mapping below is deliberately conservative: every source construct named in it is one that SYSPRO's own documentation names.
SYSPRO's own documentation is unambiguous that controls resolve through levels. eSignature access, for example, can be restricted at operator, group, role or company level, and the Operator Audit program reports what has been configured against the operator, the operator role, the company, the operator group or system wide.
D365's row-level restriction mechanism is Extensible Data Security. The shape of a policy is worth seeing before deciding whether a SYSPRO requirement needs one.
eSignatures are among the most visible controls in a SYSPRO estate, and they are restrictable at operator, group, role or company level — which makes them read as part of the security model.
SYSPRO has no segregation-of-duties rules engine in the sense D365 means. The control that exists today in most estates is a combination of eSignatures on sensitive transactions, operator-level configuration, and the visibility that comes from a modest headcount.
SYSPRO licence cost is largely settled against the modules and users the estate purchased, and it is broadly indifferent to how generously operator profiles and roles were configured afterwards. That is exactly why operator-level convenience settings accumulate: being generous with access has no cost signal.
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.
This path is explicit that where a decision cannot be made from evidence, it says so rather than offering a plausible-sounding default. Applying that honestly to security produces a short list that belongs in the discovery plan rather than in the design.
Extract effective configuration per operator, not per role. Group operators by nominal role and diff within each group. Every unexplained difference becomes a discovery item. Classify every configured control by the level it sits at. Operator, group, role, company or system-wide.
Take an inventory controller in a two-company SYSPRO estate. Nominally they hold one role from Role Management. In practice their operator profile carries additional configuration, an eSignature applies to one of the transactions they perform, and a custom Application Builder screen sits over one of the programs they use.
SYSPRO and D365 F&O both use the word "role", and that is close to where the resemblance ends. A SYSPRO role pre-configures settings that land on the operator profile, and the operator remains the security subject; a D365 role is purely an authorisation object, and a user with no roles can do nothing.