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
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
| Column | Source | What it tells you |
|---|---|---|
| FROM Role | RLFRROLE — source role. | The role that contributes its security setup. |
| TO Role | RLTOROLE — target role or user. | The role or user that inherits the security. JDE treats users and roles in the same table. |
| Effective Date | RLEFFDATE — start date. | Day the inheritance starts. |
| Expiration Date | RLEXPIRDATE — end date. | Day the inheritance ends. Empty means no end date. |
| FU Role 1 | RLFUROLE1 — 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.
| Field | What to enter |
|---|---|
| TO Role | The user or role that receives the security inheritance. Mandatory. |
| FROM Role | The role that contributes its security. Mandatory. |
| Effective Date | Start of the inheritance window. Mandatory. |
| Expiration Date | End of the window. Leave empty for an open-ended inheritance. |
| FU Role 1 | Optional 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.