Security Workbench to role-based security: rebuilding JD Edwards access control in D365

How JD Edwards' Security Workbench — eight security types, role sequencing and a *PUBLIC baseline — translates into D365's bottom-up, purely additive role-duty-privilege-entry point hierarchy, including the one JDE capability, column security, that has no clean D365 equivalent at all.

What you will be able to do

• Explain D365's role-duty-privilege-entry point hierarchy and why it is generated bottom-up and purely additive
• Enumerate JDE's eight most commonly configured Security Workbench security types and identify which have no clean D365 equivalent
• Use Extensible Data Security (XDS) as the nearest analogue to JDE row security, including its documented limits
• Contrast JDE's User/Role/*PUBLIC resolution order and role sequencing with D365's flat additive model
• Compare segregation-of-duties practice in both systems, and licensing and auditing implications of role design
• Convert a JDE role with row security into a D365 role, duty set and XDS policy

Introduction

Security is one of the few domains in this migration where JD Edwards is arguably the more sophisticated system on paper — Security Workbench exposes many distinct security types behind one screen, several of which have no formal D365 counterpart at all — while D365's model is simpler in shape but fundamentally different in how it…

The D365 hierarchy: role, duty, privilege, entry point — generated bottom-up and additive

D365 security is built from the bottom up. An entry point is a specific menu item, form or action the application actually exposes. A privilege groups related entry points at a chosen access level (Read, Update, Create, Delete).

JDE's Security Workbench: eight principal security types behind one screen

Security Workbench (P00950) is JD Edwards' single administration point for access control, and its power comes from the breadth of security types it configures from one screen. The eight most commonly configured, each restricting a different dimension of access, are all defined against the same User, Role or *PUBLIC target:

Row and column security: JDE's power, and where D365 stops matching it

Row security restricts which data rows a user or role may access within a given table or application — commonly, restricting a set of Business Units, a range of Address Book numbers, or a company range — transparently, regardless of which application or report reads the underlying data.

Resolution order: User, Role, *PUBLIC and role sequencing, vs D365's flat additive model

JDE resolves security through a defined hierarchy: a User-level definition, if one exists, takes precedence; failing that, Role-level definitions apply, evaluated in sequence number order across every role a user is assigned, so that a more specific role can restrict — not just add to — what a broader role or the *PUBLIC baseline would…

Segregation of duties: JDE's third-party habit vs D365's native (lighter) engine

JD Edwards has no native segregation-of-duties engine. Sites that need SoD assurance — and most sites of any regulatory size do — build it one of two ways: a manual matrix maintained against Security Workbench role and action definitions, reviewed periodically, or a dedicated third-party GRC product (Fastpath and SailPoint are common…

Licensing: JDE's periodic true-up vs D365's continuous role-driven cost

JDE licensing is typically structured around named users and licensed modules, reconciled through a periodic true-up exercise — a scheduled point at which actual usage is compared against contracted entitlement and any gap is settled.

Auditing: OMW's object history vs D365 database log

JDE's strongest native audit trail is not about business data at all — it is about development objects. Object Management Workbench (OMW) tracks every check-out, check-in, version and promotion of a program, application or version between environments, giving a complete, structured history of who changed what code and when it moved…

A practical role-design method, with a worked conversion

The most reliable way to design D365 roles for a JDE migration is to build from business process outward, not from the existing Security Workbench definitions inward:

Knowledge check

Summary

JDE's Security Workbench genuinely does more, in more dimensions, from one screen than D365's role model attempts to — eight security types, sequenced role overrides, and a *PUBLIC baseline everyone inherits by default.