The Admin console is the org-wide view of everything running on Helix: every project across every workspace, every deployment, every authentication in use, and the trail of administrative actions. Open it at app.helix.tray.ai/admin, or with the Admin button in the dashboard header. The button appears only for org admins, so if you cannot see it, you do not hold the Admin role in that organization.
The console is where you answer questions the builder dashboard cannot, such as which apps are shared with the whole organization, or which projects are using a particular credential.
Overview
The landing section is a set of feeds, each showing roughly the last 10 items.
Recently created projects. Each entry carries the project title, its workspace, the third-party services it connects to, when it was created, when it was last deployed, the AI-written description of what it does, and who it is shared with. Reading this feed once a week tells you what your organization started building, without asking anyone.
Recent deployments. The most recent deployments across every workspace.
Recent activity. A short preview of the activity trail, with the full list under Recent activity.
Recently linked authentications. A feed of credentials newly put to work, showing the authentication, its type, its scopes, the workspace it came from, the project that linked it, who linked it, and when. This is the feed most worth watching: it is where a broadly-scoped credential entering a new project becomes visible.
Projects
Every project in the organization, not only the ones in your workspaces. Each row shows:
| Column | Contents |
|---|---|
| Project | Name and AI-written description |
| Connected services | The third-party services the project calls |
| Workspace | Which workspace owns it |
| Created | When it was provisioned |
| Last deployed | When the most recent deployment went out |
| Shared with | The project’s Access Control state |
| Open app | A link that opens the live app, at its project URL when one is set |
The Shared with column is the org-wide answer to “who can open this app”. It is faster to scan here than to open each project’s Access Control tab one at a time.
Deployments
Every deployment across the organization:
| Column | Contents |
|---|---|
| Status | Ready, Deploying, or Error |
| Deployment ID | Copyable, for support requests and for matching against an execution trace |
| Project | Which project deployed |
| Workspace | Which workspace it belongs to |
| Environment | The environment the deployment targeted |
| When and by whom | Timestamp and the person who deployed |
The deployment ID is the identifier that links a deployment to a specific execution trace in the project’s Logs tab, so copy it from here when you investigate a failed run.
Scheduled jobs
Every scheduled job in the organization, newest deployment first:
| Column | Contents |
|---|---|
| Job | The job’s file name, the description its code carries, and a marker when the job allows overlapping runs |
| Schedule | The cadence in words, with the cron expression on hover. A job firing every 15 minutes or more often is flagged as high frequency |
| Timezone | The timezone the cron is evaluated in |
| Project | The project the job belongs to, linking to its Scheduled Jobs tab |
| Workspace | The workspace that owns the project |
| Status | Active or Paused |
Search across job names, descriptions, and project names, and filter by All, Active, or Paused. The active and paused counts beside the filter cover everything your search matches, not only the tab you are looking at, so switching tabs does not move them.
This is the page that answers “what runs in this organization when nobody is watching”. Read it for two things: jobs firing far more often than their purpose warrants, and jobs still active in projects nobody owns any more.
Pause and resume live on the project’s own tab, not here, so use the project link to act on a row. View logs in a row’s actions menu opens that job’s runs in the project’s Logs tab.
Recent activity
The full activity trail: administrative actions across the organization, each with the action, the person who performed it, the workspace, and the timestamp. It covers project creation and deletion, deployments, access grants, access-setting changes, authentication creation and deletion, role changes, scheduled jobs appearing, disappearing, being paused and resumed, and changes to a project URL or the organization namespace.
Authentications
Every authentication in use across the organization:
| Column | Contents |
|---|---|
| Service | The third-party service the credential is for |
| Type | OAuth 2.0 or API Token |
| Workspace | The workspace the authentication came from |
| Scopes | What the credential is permitted to do |
| Projects | How many projects use it. Hover to see which ones |
| Created by | Who created it |
| Created on | When |
The project count with its hover list is the reverse lookup you need during an incident: if a credential is compromised or a vendor rotates keys, this tells you which apps are affected before you start guessing.
Refresh behavior
Most of the console refreshes on its own about every two minutes, and each section has a manual refresh. If you have just made a change and do not see it, refresh rather than assuming it failed.
What to look for
Three patterns are worth checking on a regular pass.
Over-broad sharing
Start with the Shared with column on the Projects list. An app shared with the whole Organization is available to everyone with a login, including people who have nothing to do with the team that built it.
The combination that deserves a direct conversation is Organization-wide sharing plus a broadly-scoped authentication. An app that anyone in the company can open, calling a system through a credential with wide permissions, gives every employee an indirect path to whatever that credential can reach. Cross-check the project on the Projects list against its credential on the Authentications list before you decide it is fine.
Unexpected role promotions
The activity trail records every role change. A new Admin means a new person with org-wide visibility and the ability to share any app with the entire organization. Reconcile role changes against what you approved.
Degraded projects
Scan Deployments for Error status and for projects whose last deployment is much older than their activity suggests. When something looks wrong, open the project and check its Overview tab, which carries the success-rate gauge and the error and timeout trend for the last seven days.