Skip to main content
The AtlaSent Console is the signed-in control plane for configuring protected actions, reviewing authorization decisions, managing permits and approvals, and exporting evidence. The runtime makes authorization decisions; the Console lets people configure and inspect that activity.
Access to this guide and the Console requires sign-in. The pages, controls, and records you can see depend on your organization, role, plan, and enabled features.

​
The authorization lifecycle

Use this lifecycle to understand where every Console screen fits:
  1. Intent — a person, agent, workflow, or service proposes an action.
  2. Authority — the organization defines who or what may act and under what scope.
  3. Policy — rules evaluate the exact request and its context.
  4. Evaluation — the runtime returns allow, deny, hold, or escalate.
  5. Permit — an allow may issue a bounded, short-lived authorization artifact.
  6. Verification — the execution boundary checks the permit before acting.
  7. Execution — the connected system performs the action; AtlaSent does not perform the underlying business action.
  8. Evidence — records link the request, decision, policy, permit, verification, and reported outcome.
An allow decision does not prove that execution occurred. Verification proves that a permit check succeeded; execution evidence must come from the execution boundary or connected system.

​
Primary navigation

The reduced signed-in workspace contains 13 primary screens. Additional advanced and administrative screens may appear for owners and administrators. They are intentionally outside the primary pilot navigation and should be used only when the relevant feature is enabled.

​
A good first session

1

Confirm who you are acting for

Read Acting for: Organization in the organization switcher before making changes or interpreting records. Membership, authority, billing, and evidence are tenant-bound.
2

Review Protected Actions

Confirm the action type, enforcement mode, and authority scope for the operation you want to govern.
3

Review the active policy bundle

A draft policy is not runtime authority. Confirm that the intended bundle and version are active before relying on results.
4

Inspect Decisions and Permits

Open a decision, read the matched policy and reason, then follow its permit and verification links when present.
5

Export evidence

Use Audit Trail or Reports & Evidence to prepare the evidence required for your review process.

​
Team members and external collaborators

A person can belong to more than one organization. The organization switcher selects the one authority boundary for the current action; it does not combine data or authority across organizations. In Users & Roles, invite an internal team member or a time-bounded external consultant. External access is labeled, requires an end date, and cannot hold the organization-owner role. The relationship label does not itself grant authority: roles, policy, delegation, approvals, and per-request evaluation still apply. Learn the full model in Organizations and memberships.

​
Common controls

​
Next steps

Screen and field reference

Understand what every primary screen and field means.

Accounting Demo

Run the signed-in access-authorization lab in the isolated demo organization.
If you are integrating through the API, continue to the Quickstart after you understand the Console workflow.