Role permissions and the SOD matrix rebuilt on duties, privileges and entry points

QAD grants application resources straight to a role and enforces separation through a category matrix with conflict levels. D365 F&O builds every role from entry points upwards, has no category object at all, and turns the resulting role catalogue into a licence bill. This chapter maps the constructs, names the ones that have no equivalent, and gives a role-design method that produces a defensible catalogue instead of a translated one.

What you will be able to do

• Rebuild a QAD role catalogue on the D365 role, duty, privilege and entry point model rather than translating grants one for one
• Convert a SOD category matrix into duty-pair segregation rules, and say what is lost when you do
• Choose between legal-entity scope, Extensible Data Security and duty design for each data restriction you inherit
• Avoid using Extensible Data Security where it corrupts data, and know which restriction to reach for instead
• Predict the licence tier a role implies before it is assigned to anyone
• Produce an auditable record of who approved each role and each segregation override

Introduction

QAD grants access by ticking resources in a tree that mirrors the menu. You open Role Permissions Maintain, you select the programs and activities the role needs, and the role can use them.

The D365 security hierarchy, built from the entry point upwards

Before mapping anything, it is worth being precise about the four levels, because the vocabulary is used loosely in most conversations and the looseness causes real design errors.

QAD's role and permission model, mapped

The mapping table in the frontmatter is the reference; this section explains the three places where the shape genuinely changes rather than merely being renamed.

Segregation of duties: from a category matrix to duty pairs

QAD's segregation model is genuinely sophisticated, and it is the area where the migration loses the most.

Restricting data: sites, GL accounts and the Extensible Data Security decision

QAD lets you define access control for fields, sites, general ledger account updates and inventory movement codes, using user ID, role, or a combination of the two. That is four different restriction types on one mechanism.

Field-level and column-level restriction: what does not carry over

This deserves its own section because it is the gap most likely to be discovered late.

Licensing: how role design writes the cost model

QAD's licensing question is about users and modules. D365's is about entry points, and it is answered by the roles you design.

Auditing and change tracking

The database log deserves a specific warning. It is opt-in per table and per field for a reason: it writes a row for every change, and enabling it on a transaction table in a manufacturing business will degrade the system.

A role-design method for a QAD migration

Extract the current state as data, not as opinion. Pull the role list, every grant made in Role Permissions Maintain (36.3.6.5), every membership from Role Membership Maintain (36.3.6.6), the full SOD category and matrix content, every policy exception, every role exclusion, and every field, site, GL account and movement-code security…

Worked example: converting one QAD role into a D365 role

Take a QAD role held by an accounts payable clerk. In QAD it holds direct resource grants across voucher entry, payment generation, vendor maintenance and several reports, plus a field-security record hiding a cost field, plus membership limited to two entities in one domain.

Knowledge check

Summary

QAD grants resources to roles in one step and separates duties through a category matrix with graduated conflict levels. D365 F&O composes every permission from entry points upwards, has no category object, has no severity scale, and turns your role catalogue into a licence bill. The role container and the activity verbs carry over well.