Skip to main content

Activity log

The Activity log screen lists every recorded transaction on a connected application, captured at the database level. One line per (Application, User, Table, Transaction date) — the raw evidence used by the Proven conflicts view and the Object Usage Tracking statistics.

It is the fact ledger of Nomasx-1 — the data set that turns a theoretical conflict into a documented finding.

At a glance​

Nomasx-1 · Applications · Activity logAPPUSERSCHEMATABLETRANSACTION DATECOUNTOBJECT ID12JDOEPRODDTAF04112026-05-14 09:4242P041112JDOEPRODDTAF04132026-05-14 11:178P0413M12SVC_BATCHPRODDTAF41012026-05-14 02:0012 481R4154921BENEMGRSAP_PRDPA00082026-05-13 16:243PA20

Goal of the view​

For each connected application:

  • What did each user actually do? Schema + Table + Transaction date + Count tells how many rows of which table a user touched on a given timestamp.
  • Cross-check theoretical rights. Combined with the Rights matrix, an empty activity log on a user with extensive rights is the strongest revocation argument.
  • Feed the proven SoD analysis. The Proven conflicts screen intersects this dataset with the SoD details — if a user does not appear here for the relevant tables, the conflict is theoretical only.

The activity log is built from database-level triggers / auditing on the source-system tables — outside of any application-layer permission. It captures what the database recorded, not what the application believes happened.

Columns​

ColumnSourceWhat it tells you
Application IDACL_APPS_ID — application identifier. Filterable.The connected application.
User IDACL_USER_ID — user identifier, trimmed. Filterable, scoped to the application.Who performed the transaction.
SchemaACL_SCHEMA — database schema.Where the data lives — useful when several environments share the same Nomasx-1 instance.
TableACL_TABLE_NAME — database table. Filterable.Object that was written to.
Transaction dateACL_DT_TRANSACTION — timestamp.When the activity happened.
CountACL_COUNT — number of rows touched.Volume — distinguishes a one-off update from a mass operation.
Object IDACL_OBJECT_ID — source-system program.Which program triggered the write — links the row back to the rights matrix.

Tips & best practices​

  • Filter on a single User ID + sort by Transaction date descending — the latest activity narrative for that user. Quick way to know whether an account that holds risky rights is dormant or active.
  • Filter on Table to investigate a specific data set — Who touched F0411 last quarter? is answered in one filter.
  • Combine with OUT — Components — Activity log is the database picture, OUT is the application picture. Both should tell similar stories; large discrepancies point to direct database writes that bypass the application.
  • Watch Count — a single-row update is normal, a mass operation deserves a justification check.