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 |
| Created a schedule | A deployment introduces a scheduled job the project did not have |
| Deleted a schedule | A deployment lands without a scheduled job the project used to have |
| Paused a schedule | Someone pauses a scheduled job in the dashboard |
| Resumed a schedule | Someone resumes a paused scheduled job |
| 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 |
| Changed a project’s URL | A project’s alias is set, changed, or released |
| Changed the URL namespace | The organization’s namespace is set or changed, moving every project URL |
| Added an agent | A deployment introduces an agent the project did not have |
| Removed an agent | A deployment lands without an agent the project used to have |
| Changed an agent | A deployment changes an existing agent’s definition, such as its model |
| Changed a tool’s approval | A deployment changes whether a tool needs approval before it runs |
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 execution, whether an HTTP request or a scheduled job run: time, status, trigger type, the route or job, 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 execution |
| 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 |
Retention and export
Talk to your Helix contact before treating retention, export, or redaction as settled for a control document or compliance questionnaire. In particular, confirm:
- How long activity-trail entries and execution logs are retained.
- Whether the activity trail can be exported, or streamed to a SIEM.
- Whether the trail is tamper-evident.
- Whether, and how, request and response payloads in execution traces are redacted.
- Whether org admins can read execution payloads for projects outside their own workspaces.
Hosting region
Helix runs as four regional deployments: us1 (the default), eu1, ap1, and ap2. Your workspace, and every project in it, lives in one region; see regions for how that’s set and how it shows up in the CLI and dashboard URL.
This page doesn’t cover what’s guaranteed to stay in-region, such as backups, logs, or support tooling. If your organization has an EU or in-country residency mandate, confirm the specifics with your Helix contact before you deploy anything that carries regulated data.
Credentials stay out of project code today through the alias mechanism described in IT & governance.