System events

Open Admin → System events when investigating a question such as “an order changed, so why did its automation not run?” This is a read-only diagnostic history. An event says something happened; a delivery says a consumer received or processed that event; a workflow run records subsequent execution. A successful event delivery alone does not prove an external action completed.

The three sections separate those stages:

• Activity lists recorded changes to orders, production, maintenance and connected workflows.
• Automation delivery shows the consumer, delivery status, attempts and last recorded error.
• Event publishing shows attempts to record events, including waiting, failed and discarded entries.

Choose the right evidence

Question	Where to look
Who changed this record?	Record history and available audit trail.
Did an event occur?	Admin → System events → Activity.
Did its consumer process it?	Automation delivery; inspect Event publishing for publishing attempts.
Did an automation complete?	Automation/workflow run history.
What did Konnie propose or execute?	Conversation, review, and action history.
Why was access denied?	Authorized access-decision view.
Was an external write confirmed?	Integration execution and receipt history.

Access to these views is permission-controlled. Monitoring permission does not imply permission to read every protected business payload.

Investigate one task

1. Record the organization, site/environment, entity ID or order number, and the time with timezone.
2. Open the record and inspect its current state and available history.
3. Open Admin → System events → Activity and choose the relevant event type. Use the related record, actor and occurrence time to identify the event. Page through older records when needed.
4. Choose View to inspect the event's source, type and reference. Choose Check automation delivery to open deliveries filtered to that exact event.
5. Inspect status, attempts, last error and updated time. A status filter further narrows the selected event's deliveries. Remove the Event: … filter to return to all deliveries. Event publishing lists publishing attempts separately.
6. Open the matching automation, Konnie action or integration run in its owning feature. Distinguish queued, awaiting approval, failed, uncertain and completed outcomes.
7. Verify the target record or external receipt before deciding whether a retry is safe.

For example, a completed production order can generate an event consumed by a reporting workflow. If the order is complete but the report is missing, inspect delivery and run state before generating another report manually.

Read the status

For deliveries, Waiting and Processing describe unfinished handling, Delivered records successful consumer handling, and Failed identifies a failed attempt. For publishing, Recorded means the event was published and Discarded means that publishing entry was discarded. Check the last error and the owning workflow for the next action; the history does not infer the business result.

The event-type and status filters apply to server results. Page controls and the record count describe the current section and filters. Switching sections resets the page and status filter. Refresh reloads history; Try again recovers a failed read. A loading error is not evidence that no events exist.

Recovery and privacy

Use only recovery controls exposed by the owning feature and authorized for your account. The event explorer is an inspection view; it does not provide a general-purpose replay or retry button for every event. An uncertain external action needs receipt reconciliation before another write.

Exports and retention depend on the specific record type and your deployment policy. There is no universal audit-retention setting in the Organization Options cards. Share minimal evidence with support: IDs, times, state, and redacted errors. Exclude credentials and unrelated payloads.

See Automations, Integrations, Konnie governance, and Support.