Skip to main content

Rights — Users

The Rights — Users screen lists every object-level right granted directly to a user on a connected application. One line per (Application, User, Object) triplet. Only SER_RUN = 'Y' rows are returned — the rights that actually let the user run something.

This is the bottom of the security pyramid: even when a role-level rule forbids access, an explicit user-level row can override it. Auditors look at this screen for exceptions.

At a glance​

Nomasx-1 · Applications · Rights · UsersAPPUSEROBJECTFORMVERSIONRUNADDCHGDEL12APMGRP0411W0411AZJDE0001YYYN12APMGRP0413MW0413AZJDE0001YYYY12SVC_BATCHR31410—XJDE0001YNNN1 — 50 of 8 712 direct user-level rights

Goal of the view​

For each user-level right granted on a connected application:

  • What does the user have access to? Object, form, version — exactly what the source system uses to identify a callable program.
  • What can they do with it? Run, Add, Change, Delete — the four action flags. Run means open the screen; Add/Change/Delete control row-level operations.
  • Is the right justified? A direct user-level row is by definition an exception — it bypasses the role-driven security model. Every row here deserves a justification or a cleanup decision.

Columns​

ColumnSourceWhat it tells you
Application IDSER_APPS_ID — application identifier. Filterable.Which application the right applies to.
User IDSER_USER_ID — user holding the right. Filterable, scoped to the application.The user the right is granted to directly.
ObjectSER_OBJECT — technical object the right applies to. Filterable, scoped to the application.What the user can call.
FormSERL_FORM — form code within the object.Specific form within the object.
VersionSER_VERSION — processing version.Configuration variant.
RunSER_RUN — Y / N.Whether the user can open the screen at all. Only Y rows surface.
Role Action IDSER_ROLE_ACTION_ID — action identifier.Source-system action descriptor.
Add / Change / DeleteSER_ADD, SER_CHG, SER_DEL — Y / N.Row-level action flags within the form.

Tips & best practices​

  • Direct user-level rights are exceptions — the volume here should stay small. Compare against Rights — Roles to see what is normally granted via the role model.
  • Filter by User ID to obtain the full direct-grants wallet of a single user — useful when investigating an SoD conflict that the role-level matrix did not predict.
  • Flag rows with all four flags set to Y — full create/read/update/delete on a sensitive object is the heaviest individual grant and the first thing to challenge.
  • Cross-reference with the Activity log to see whether the user actually exercised the right. A high-privilege grant that was never used is often the easiest to revoke.