Helix records two different things, and telling them apart is the first step in answering any audit question. Administrative actions across the organization go into an org-wide activity trail. What an app did on a given request goes into that project’s execution logs. The activity trail answers “who changed what”, and execution logs answer “what did the app do”.
The activity trail
The activity trail is a single org-wide feed of administrative actions. Org admins read it in the Admin console, under Recent activity, with a shorter preview on the console’s Overview.
Every entry carries four fields:
| Field | Contents |
|---|---|
| Action | What was done |
| Actor | The person who did it |
| Workspace | Which workspace it happened in |
| Timestamp | When it happened |
What gets recorded
| Action | Recorded when |
|---|---|
| Deployed a project | A deployment goes out |
| Created a project | A project is provisioned for the first time |
| Deleted a project | A project is removed |
| Granted access to a project | Someone is given access to a published app |
| Changed access settings for a project | A project’s Access Control setting changes |
| Created an authentication | An authentication is linked for use by projects |
| Deleted an authentication | An authentication is removed |
| Changed a role | A member’s organization role changes between Admin and Contributor |
Those are the action types the trail produces. If an action is not in that list, do not assume it is captured.
What is not recorded there
Ordinary use of a published app does not appear in the activity trail. If you need to know who called an app, when, and what came back, that is in the project’s execution logs.
There is also no CLI command for the activity trail. The Admin console is the only place to read it.
Execution logs
Each project has a Logs tab holding one entry per HTTP request: time, status, method and path, duration, and who initiated it. Opening an entry gives the full execution trace, including the trace ID, execution ID, deployment ID, the tree of operations the run performed, which authentication each third-party call used, and the request and response payloads. See the dashboard for the full walkthrough.
Which one answers your question
| Activity trail | Execution logs | |
|---|---|---|
| Scope | The whole organization | One project |
| Granularity | One administrative action | One HTTP request |
| Where | Admin console, org admins only | The project’s Logs tab |
| Contains payloads | No | Yes, request and response bodies |
| Answers | Who changed what, and where | What the app did, and why it failed |
Open questions
Hosting region
Helix environments are named by an identifier, and the production identifier is us1. That is the value you pass to helix env set, and it is the only region identifier the shipped product uses.
Beyond that identifier, residency is unconfirmed. There is no shipped control for pinning an organization’s data to a chosen region, and no published list of available regions. If your organization has an EU or in-country residency mandate, raise it with your Helix contact before you deploy anything that carries regulated data.