Skip to main content

Users without roles

The Users without roles screen lists every active user account that holds no role on a connected application. One line per (Application, User) pair. These accounts can log in to the application but cannot do anything once inside — or, more concerning, may be inheriting permissions through an implicit / wildcard mechanism that needs auditing.

The screen filters on USR_STATUS = '01' so only active accounts surface. Inactive accounts without roles are simply dormant and visible on the Users screen.

At a glance​

Nomasx-1 · Security · Users without rolesAPPUSERSTATUSCREATEDLAST LOGIN12SVC_BATCHActive2017-04-022026-05-1412NEW_HIRE_05Active2026-05-02—21FORMER_USRActive2018-06-222024-09-04WHAT TO DOEither grant the user the missing role(s), or deactivate the account in the source system if it has no purpose.

Goal of the view​

For each active account known to a connected application but without a single role attached:

  • Why does the account exist? Either a fresh onboarding awaiting role assignment, or a former user whose roles were revoked but whose account was not deactivated. Both are normal — neither should stay in this state for long.
  • Is the account still in use? Last login tells whether anyone is still actively trying to log in despite having no roles. A long-dormant account in this state is the easiest deactivation decision.
  • Should the account be deactivated or granted roles? The choice between the two is the action the screen exists to drive.

The screen is a recurring deliverable of the quarterly access review and a leading indicator of leaver-process gaps.

Columns​

ColumnSourceWhat it tells you
Application IDAPPS_ID — application identifier from the source system.Which application the orphan account belongs to.
User IDUSR_ID — user identifier (technical login). Lookup linked to the user catalog, scoped to the application above.The orphan login.
StatusUSR_STATUS — boolean rule, 01 means Active. Hardcoded by the underlying query, so every row shows Active.Confirmation that the row really is an active account.
Creation DateUSR_DT_CREATION — date.When the account was created — distinguishes new-hire accounts from forgotten leftover accounts.
Login DateUSR_DT_LOGIN — date.Last authentication. Combine with Creation Date to interpret the row.

The two filter inputs above the grid (Application ID and User ID) accept the standard contains / equals / not equals / starts with / ends with operators.

Tips & best practices​

  • A new account < 1 month old with no login is almost certainly a fresh onboarding waiting for role assignment — coordinate with the security administrator to grant the roles or notify HR.
  • An old account with a recent login is the most concerning row: someone is still authenticating into an application where they cannot do anything official. Investigate before deactivating — they may be inheriting roles through a wildcard mechanism.
  • An old account with no login in the last six months is the cleanest deactivation decision.
  • Click on a row to open the Users Audit screen, which shows the historical role wallet — useful to understand what the user used to have before revocation.