Skip to main content

Role Relationships

The Role Relationships screen maintains the JD Edwards role-inheritance graph. One line per (FROM Role, TO Role, Effective Date). Each row says: the TO role inherits the security setup of the FROM role, during this date window.

It is the screen the security team opens to grant a junior role the rights of a senior one — or to extend the effective window of an inheritance that is about to expire.


At a glance

Nomajde · Security Maintenance · Role RelationshipsFROM ROLETO ROLEEFFECTIVEEXPIRATIONFU ROLE 1FIN_BOOKKEEPERDUPONT.J2026-01-012026-12-31PROC_BUYERMARTIN.S2025-09-012026-06-30AR_CASHIERGARCIA.L2026-03-15

Goal of the view

For each role-inheritance line:

  • Inheritance, in plain rows. A relationship row says: FROM Role grants its security setup to TO Role, between Effective Date and Expiration Date. The TO Role can be a junior role or a user — JDE treats both the same way.
  • Date-driven access windows. Effective and Expiration dates make the inheritance temporary by default. Expirations that fall in the next 30 days surface in amber; expirations in the past in red — both call for review.
  • Bulk-loadable. The screen supports Excel upload — when the SI delivers a new bundle of role relationships for a roll-out, import the file instead of typing 200 rows by hand.

Columns

ColumnSourceWhat it tells you
FROM RoleRLFRROLE — source role.The role that contributes its security setup.
TO RoleRLTOROLE — target role or user.The role or user that inherits the security. JDE treats users and roles in the same table.
Effective DateRLEFFDATE — start date.Day the inheritance starts.
Expiration DateRLEXPIRDATE — end date.Day the inheritance ends. Empty means no end date.
FU Role 1RLFUROLE1 — secondary role.Optional second role mixed into the inheritance — used for role mixes (the FROM role plus a side role).

Internal JDE fields kept on the row but hidden: role type, system role flag, default role flag, FU roles 2 to 9, plus the audit columns.


Edit dialog

Click Add in the toolbar to register a new relationship, or double-click a row to edit one. The dialog is a single form with the five visible fields.

FieldWhat to enter
TO RoleThe user or role that receives the security inheritance. Mandatory.
FROM RoleThe role that contributes its security. Mandatory.
Effective DateStart of the inheritance window. Mandatory.
Expiration DateEnd of the window. Leave empty for an open-ended inheritance.
FU Role 1Optional second role to mix into the inheritance — used in rare role-blend setups.

The triple (TO Role, FROM Role, Effective Date) is the unique key — JDE uses it to look up the inheritance at sign-on time.


Tips & best practices

  • Always set an Expiration Date unless the relationship is genuinely permanent. Time-boxed inheritances surface on the dashboard before they expire — a much safer pattern than open-ended grants.
  • Use the Excel upload for SI-delivered bundles. The standard Add flow handles single rows; the upload is meant for the dozen or two dozen rows that ship with a new module.
  • Sort by Expiration Date ascending to bring the next expirations to the top — the natural list for the monthly access-review.
  • Check Nomasx-1 → Conflicts → Summary by Role after granting a new inheritance — combining two roles often creates a SoD conflict that was not visible on either role alone.