How to Review the Security Audit Trail in EDGEBIC

EDGEBIC by User Solutions records every security event, sign-ins, failed sign-ins, lockouts, user and role changes, in an append-only trail inside the database. There is currently no viewing screen for that trail in the application. It exists as a durable record your administrator or support can query when a compliance or investigation question genuinely needs it. Here is how to get at it, and which screens answer the neighboring questions you can handle yourself.

Every task in this library is mapped on the EDGEBIC how-to hub. For the access model the trail is recording, start with how to create a role.

Before You Start

• Know whether your question is about access or about production. That single distinction routes you to completely different places, and getting it wrong costs an afternoon.
• Know the window you care about. "Recently" is not something anyone can query, and the trail grows with every sign-in in the plant.
• Know that the trail is append-only. Nothing has been deleted, so if an event happened it is recorded, even for accounts that were later renamed or removed.

Step 1: Route the Question First

Most questions people bring to "the audit log" are not security questions at all.

The first four you run yourself in seconds. Only the last two need anyone to touch the database.

Step 2: Check What Is Already On Screen

Open Settings, then Security, then Users. The grid carries the columns that answer the everyday version of most access questions.

For a stuck user this is usually the whole investigation. Select them, click Unlock or Activate / Deactivate, and they are working again. No extract required.

Step 3: Use the Real Reports for Schedule Questions

If the question turned out to be about the plan rather than about access, two genuine reports cover it.

Reschedule History gives every reschedule event in a date window: old versus new start and end, days moved, who triggered it, and the reason if one was entered. This is the "who moved my job and why" report. See how to run the reschedule history report.

Resource Replacement Audit gives every work center swap with the actor and reason, which is the where companion to Reschedule History's when.

For a single job's full story, the job audit trail pulls it together. Both report grids support the standard filtering tools, covered in how to filter a report with the filter editor.

Step 4: Request a Security Trail Extract

When the question genuinely needs the security trail, raise it with your administrator or support. Make the request specific, because a vague one produces either nothing useful or an unreadable volume of rows.

Give them four things:

1. The window. Exact dates, not "last month or so."
2. The scope. One username, or plant-wide.
3. The event kinds. Sign-in events, account changes, permission changes, or all three.
4. What the answer is for. An auditor's evidence pack and a "what happened to Dave this morning" question want very different extracts.

Step 5: Read a Sequence, Not a Row

Whatever comes back, single rows rarely settle anything. Sequences do.

• Several failed sign-ins in one minute, then a lockout. A person mistyping, or a saved password on a second machine.
• Failed sign-ins spread across an hour, outside that person's shift. Worth escalating.
• A password reset, then failures, then a success. Somebody was still using the old password on a device they forgot about.
• A permission change, then activity on a new screen. The access change and its use, in order.

How to Check You Got the Right Answer

• The window matches. Confirm the extract's first and last timestamps actually bracket the period you asked about.
• The account states line up. Cross-check a lockout in the extract against the Locked column on Users.
• You are not in the wrong trail. If the answer you needed was about a job rather than an account, you want Reschedule History, and no security extract will ever contain it.

Common Mistakes

• Hunting for a viewing screen. There isn't one. The trail is queried, not browsed, and time spent looking for the menu item is time lost.
• Asking for "the audit log" with no window. Every sign-in in the plant is in there. Scope the request.
• Expecting production changes in it. Access only. Schedule changes live in the reports.
• Reading one row in isolation. A single failed sign-in means almost nothing.
• Only asking after an incident. A periodic look at the Users grid finds the account nobody deactivated when someone left, which is the thing most worth finding, and it needs no extract at all.

See how EDGEBIC controls and records access across the plant on the EDGEBIC product page.