Skip to main content

Users

The Users screen is the central catalog of every account known to Nomasx-1 across every connected application — JD Edwards EnterpriseOne, SAP, NetSuite or any custom ERP plugged in through its own query. One line per (Application, User) pair: it is where to look up an account, check whether it is still active, see when it last logged in, and decide whether it should still exist.

The list is fed automatically from each source system at scan time (security tables for the ERP, optional LDAP / Active Directory verification on the side).

At a glance​

Nomasx-1 · Security · UsersRefreshApplication IDUser IDAPPUSERNAMESTATUSCREATEDLAST LOGINLAST USAGEUPDATED12APMGRAP ManagerActive2019-03-142026-05-142026-05-132026-05-1412ARMGRAR ManagerActive2020-09-022026-05-132026-05-122026-05-1412LEGACY01Legacy accountInactive2014-06-222023-11-042022-08-192025-12-0121BENEMGRHR Benefits MgrActive2021-01-082026-05-142026-05-142026-05-141 — 50 of 1 248Page 1 ▾ · 50 ▾ · ‹ ›KEY POINTSSpot dormant accounts (last login > 6 months), recent additions, accounts with no usage. Each row links to the User Audit screen for the full per-user history.

Goal of the view​

For each user known to any connected application, answer four questions in one glance:

  • Does the account still need to exist? A user with no login in the last few months on an active application is the first one to question.
  • Is the account active or disabled? Status Active / Inactive reflects the source-system state — Inactive accounts may still hold roles that need to be reviewed.
  • When was the account created? Helps to align with HR onboarding and identify accounts created outside the standard process.
  • What is the difference between login and usage? Last login is the last authentication; Last usage is the last actual transaction recorded by the source system. An account that logs in but never uses anything is a red flag.

The screen is the entry point for the account-hygiene review that auditors expect every quarter, regardless of the underlying ERP.

Columns​

ColumnSourceWhat it tells you
Application IDUSR_APPS_ID — Application identifier from the source system (numeric reference).Which application the row applies to. Several rows for the same user means the user exists on several applications.
User IDUSR_ID — User identifier (technical login). Linked to the user lookup catalog.The user's technical login as known to the source system.
User NameUSR_NAME — Display name.Human-readable name of the user.
StatusUSR_STATUS — Boolean rule, 01 means Active.Account state in the source system. Green chip Active when the value is 01, red chip Inactive otherwise.
Creation DateUSR_DT_CREATION — date.When the account was created in the source system.
Login DateUSR_DT_LOGIN — date.Last authentication captured by the source system.
Last UsageLAST_USAGE — date computed by the connector.Last time the user actually used something — distinct from a simple login.
Last UpdateUSR_DT_UPDATE — date.Date of the last refresh on the source row.
JDE-specific

On JD Edwards EnterpriseOne, the Last Usage date is computed from the Object Usage Tracking records read through the LICENSE_JDE_OUT connector. Other source systems can feed the same column by exposing an equivalent query — for example a usage log table in a custom ERP, or session-audit events in SAP / NetSuite. The screen itself is identical; only the underlying query changes.

Hidden columns kept on the row for downstream screens: USRP_TECHNICAL, USRP_GENERIC, USRP_ID_LINKED, USR_REGISTRATION, USR_DT_REFRESH, USR_UKID. They surface on the User Audit and Duplicate Users screens.

The two filter inputs above the grid (Application ID and User ID) accept contains / equals / not equals / starts with / ends with operators — the standard server-side filter shape used across Nomasx-1.

Tips & best practices​

  • Sort by Last Login ascending to bring dormant accounts to the top of the list. Combine with the Inactive status filter to short-list the candidates for removal.
  • Compare Last Login with Last Usage. An account that logs in regularly but has not used a single transaction in months is either a technical account that should be tagged as such, or a real user whose access is no longer needed.
  • The Creation Date drives onboarding reconciliation. Filter the last quarter and compare with the HR onboarding sheet — every new hire must appear, and every appearance must match a hire.
  • A user across several applications is normal, several users with the same alpha name is not. When the latter happens, jump to the Duplicate users screen which highlights it explicitly.
  • Click the row to open the Users Audit screen scoped to that user — full role history, country, business unit, last usage by module.