What the System Logs show
Answer who changed what, when and for which client in seconds: the Audit Log keeps an unalterable record of every change and Export CSV hands the rows to an auditor, while Email, System, Operations and Sessions logs cover the rest.
Log streams
The System Logs menu in the sidebar lists five streams: Audit Log, Email Log, System Log, Operations and Sessions. Opening System Logs lands on the first one, Audit Log.
Search
The Search logs box matches the action, the resource type, the resource's ID, or the acting user's name or email.
Filters
All actions, All resources, and All users narrow the list to one action type, one resource type, or one person.
Date range
From and to date pickers narrow the list to a time window.
Export and count
Export CSV downloads the rows that match the current filters, up to 10,000 of them, with the time, user, action, resource, IP address, client and the field-by-field changes. The entries count on the right reflects the same filters.
A log entry
One row shows the action, the resource type, who did it (System for an automated change), and how long ago, with the client on rows that belong to one. Click the row to open it.
Browse
On this page
System Log
Category and filters
The All and Elise buttons, plus All Levels and All Sources, narrow the list to a kind of event or one source.
A log row
Time, Level, Source and Message for one event. When the same message fires many times in a row, a repeat counter such as x21 sits next to the time, so identical events collapse into one line instead of filling the page.
Operations
Filters
All Jobs, All Statuses and a date range narrow Cron Job History to one scheduled job or one status.
Cron Job History
Started, Job, Status, Duration and Message for one run of a scheduled background job.
Why it works this way: What the System Logs show
The audit log is kept as a permanent record, and its API rejects any edit or delete.
Opening a row shows exactly what changed. Each changed field is listed with its old value and its new one, and the full event sits underneath. Filter the action to one value, such as TICKET_REASSIGNED, to see every handover across all tickets.
The Email Log lists every outbound email with its ticket, recipient, subject, template, status, sender and date. Its status filter offers Queued, Retrying, Sent, Failed, Suppressed, Paused and Cancelled, and a failed row shows the error the provider sent back.
Under the outbound emails sits an Inbound Email card. It is read-only and lists every email that came in to the help desk mailbox and what became of it: the ticket it opened, or the reason it was skipped. A skip reason is one of: sent by the portal's own mailbox, a no-reply or bounce sender or a quarantine digest, an automatic reply, a parsing rule that said to skip it, a rule-tester forward, a sender past the new-tickets-per-hour limit, or an unapproved sender while unapproved mail is set to reject.
The Sessions log lists sign-in events: Signed in, Session expired, Session terminated by admin, Session limit reached, Sign-in blocked, Failed sign-in attempt and IP auto-blocked. Filter by event type, IP address or date.
Elise Actions lists every action Elise proposed or ran, with the time, the tech it ran for, the action, the record it touched and its status. An executed action that can still be undone carries a Rollback button. This page is not in the System Logs menu. Open it from a via-Elise badge on an audit row.
Ask Elise "why was ticket 25 reassigned" and she reads that ticket's audit and event trail, then answers with the setting, its current value and the recorded event, or says plainly when the state was never recorded.
Other ways to do this: What the System Logs show
Export CSV
Click Export CSV on the Audit Log to download the rows matching the current filters.
Questions this page answers
What gets audit-logged?
Every create, update, and delete across the admin and client portals writes an audit row: who did it, the action, which record and client it touched, and a field-by-field diff of what changed. The audit log is immutable, entries cannot be edited or deleted, so it stays a trustworthy record of what happened. Even if the database is briefly unavailable, audit writes fall back to local disk so nothing is lost.
How do I see what emails the platform sent?
The email log lists every email the portal sent out. Each row shows the linked ticket if there is one, the recipient, the subject, the template, the status, the sender, and when it sent. The status filter offers seven choices: Queued, Retrying, Sent, Failed, Suppressed, Paused, and Cancelled. A row can also read SENDING while a message is still on its way out. That is a real status, just not one of the filter choices. A failed row also shows the error the provider sent back. Inbound emails do not show here. They show up in the system log under the email-listener source.
What does the Elise log show?
This log lists every action the AI assistant proposed or ran, one row per action. Each row shows the time, the tech it ran for, and a short line about what it did. It also shows the entity type it touched and its status: pending, confirmed, executed, failed, or rolled back. An executed action gets a Rollback button, as long as no one has rolled it back yet. A row marked Ran without release is an action that Elise's own chat would send to a second person to release, but no one released it. Point at the badge to read that it ran through an AI app on the person's own rights.
What happened to an email that never became a ticket?
The Inbound Email card sits under the delivery log on this page. It lists every email the help desk mailbox has taken in, and what came of each one. A row links to the ticket it opened. If no ticket was made, the row names the rule that skipped it. The rules are: mail sent by this portal's own mailbox, a no-reply or bounce sender, a mail filter's quarantine digest, an auto reply such as an out of office, a parsing rule set to skip, a rule-tester forward, a sender past the new-tickets-per-hour cap, and a sender you have not approved while unapproved mail is set to reject. The email itself is still in the mailbox, in the Skipped folder. To give it another try, mark it unread there. The poller takes it again on its next pass. Mail taken in before this log existed reads Not recorded. The reason was not stored then, so nothing is guessed.
Was this helpful?