How PeopleSoft's permission lists, roles, user profiles, definition security, query security and row-level security records decompose onto D365's bottom-up role, duty, privilege and entry point hierarchy, Extensible Data Security and native segregation of duties — and why several parts of a permission list leave application security altogether.
The organisational chapter for this path settled what each business unit becomes and how the reference data that SetIDs used to share is going to be shared instead. This chapter is about who may touch the result.
D365 composes four levels above the entry points they secure, and the composition runs upward from objects the application already contains.
This is the central mechanical task of the workstream, and it is worth doing as a table rather than as a conversation, because the destinations are not intuitive and half of them are outside the security team's remit.
PeopleSoft restricts rows by indirection. The user profile carries a row security permission list; delivered security views are keyed on that permission list and hold the business units, SetIDs or ledgers it may see; search records on the secured components reference those views rather than the underlying tables.
These two get their own section because both are real controls, both are maintained inside PeopleSoft security today, and neither ends up in the D365 role catalogue.
Four PeopleSoft features have no D365 counterpart, and each is small enough to be missed and consequential enough to matter.
PeopleSoft has no delivered engine that blocks a conflicting combination of access at the moment somebody creates it. Segregation of duties in a PeopleSoft estate is a permission list and role design convention, enforced by review and sometimes checked after the fact by a bolt-on governance product.
In PeopleSoft, security design and licence position are separate conversations that meet at a contract renewal. In D365 they are the same conversation, continuously.
A PeopleSoft estate arrives with two expectations and they land in different places.
The most consequential decision in this workstream is what the design starts from. Starting from the permission list and role export produces a D365 catalogue carrying all of PeopleSoft's accumulated structure and none of D365's simplifications, because the export describes objects shaped by upgrades, acquisitions, one-off projects and…
Consider a role assigned to payables clerks. It holds three permission lists. The first grants the voucher entry and matching components at update action, plus two inquiry components display-only. The second grants a process group containing the voucher posting and matching jobs, and a query profile with access to a payables query tree.
PeopleSoft stacks permission lists inside roles inside user profiles, and the resemblance to D365's duties inside roles is close enough to be dangerous. A permission list is a container for a dozen unrelated permission kinds, and their destinations differ: page and process access become privileges grouped into duties, PeopleTools and…