EBS Audit Trail & Access Review Copy link

➜ Back to AI Skills
Description
Category: Audit and Security
Plugin: Blitz Report Excel Add-in Skills (br-audit-trail)
Works with: Claude in Excel, Microsoft 365 Copilot in Excel

Answer "who changed what, when" across Oracle EBS setups and access: mine the FND Audit Trail reports for setup and profile changes by record and column, correlate with user login history and responsibility assignments, and produce a reviewable change narrative for an audit window or an incident. Read-only.

When to use it

  • Use when the user asks who changed a setup, wants a segregation-of-duties or access review, needs audit evidence for a period, or is investigating an unexpected configuration change.
Install
  1. Download the skill zip. br-audit-trail.zip
  2. In Claude in Excel open Customize > Skills > Create skill and upload the zip.
  3. Connect the Blitz Report Excel add-in to your Oracle EBS instance, then ask Claude for the task in your own words.

Requirements: Blitz Report and the Blitz Report Excel add-in, connected to your Oracle EBS instance, plus Claude in Excel or Microsoft 365 Copilot in Excel.

🚨 Blitz data = Excel worksheet UDFs, not MCP tools/connectors. Extract data only by writing =br_...() into a cell (via execute_office_js) and reading the spill — never tool_search for br_*, never refresh_mcp_connectors, and never conclude "no Oracle EBS / Blitz connector is set up" (the Blitz Report add-in is an Excel add-in, not an MCP connector, so it never appears in the connector list — its absence there is expected). Load the extraction mechanism first: read_skill("br-run-reports").

Performance: read br-analytics-standards at the start of every run.

When to use

"Who changed this supplier's bank account", "what setup changed last month", "audit evidence for the Q2 window", "who had this responsibility and when did they last use it", "unexpected config change — investigate". Read-only by nature — this skill produces evidence and narrative, never changes anything.

Inputs

  • The question — an entity/table, a user, or a time window; at least one is required.
  • Date range — required for window reviews; ask rather than defaulting wide.

Reports used (authoritative names — do NOT broad-search for them)

Report (exact name)Role
FND Audit Setupwhich tables/columns are under AuditTrail — ALWAYS run first (see the hard rule)
FND Audit Table Changes by Recordthe change log per record — who, when, what row
FND Audit Table Changes by Columnold value → new value per audited column
FND User Login Historysession context around a change — who was on, from where
FND User Responsibilitieswho holds which responsibility, with dates — the access half
FND Usersaccount status, last logon — dormant/shared-account signals

Pass the exact names; fall back to a search only on #BLITZ_REPORT_NOT_FOUND.

🚨 The hard rule — audit coverage first, never silence

AuditTrail only records tables the customer has ENABLED it for. Run FND Audit Setup first, and:

  • If the asked-about table/column is NOT audited, the answer is "not auditable — AuditTrail is not enabled for X", stated up front — NEVER "no changes found", which reads as a clean bill.
  • Every window review names its coverage: "this narrative covers the N audited tables; changes outside them are invisible to AuditTrail." This distinction is the whole integrity of the deliverable.

Workflow

  1. Coverage: FND Audit Setup → what is auditable. Answer the coverage question explicitly.
  2. Extract the change log for the scope (by record + by column for the audited entities in the window), and the access context (login history, responsibilities) — one call per report.
  3. Build the change narrative: per change — who, when, old → new, and the session context (login proximity). Group by entity and by user; flag the review-worthy patterns:
    • changes outside business hours or from atypical users,
    • rapid change-and-revert pairs (old→new→old),
    • changes by dormant or generic accounts,
    • high-sensitivity columns (bank accounts, profile values, flexfield security) — call these out by name.
  4. Access review mode (when asked): responsibilities per user vs last-login recency — unused grants, active grants on dormant accounts, and users holding review-flagged combinations (the combination list is CONFIG — the customer's SoD matrix, not ours; label placeholders).
  5. Deliverable: the narrative sheet (filterable change log), the flagged-patterns summary, and the coverage statement. Dashboard optional (br-data-dashboard) for window reviews.

Hard rules

  • Never characterize a change as wrong or unauthorized — report who/what/when and the pattern; judgment belongs to the reviewer.
  • Old/new values may be sensitive (bank accounts). Present them where the question requires, and never copy them beyond the deliverable sheet.

Degradation rules

  • AuditTrail enabled but shadow tables empty for the window → "audited, no changes recorded" — that IS a clean answer, distinct from not-audited.
  • Login history purged for part of the window → narrative proceeds, context gap stated.

Talk in the user's language

Users, screens, setups, dates — never br_* functions, shadow tables, or helper sheets.