Customer Portal
The AxonFlow Customer Portal is the enterprise operations surface around the runtime. It gives platform, security, compliance, and engineering teams a shared place to review governed executions, manage operational access, inspect usage, coordinate approvals, and run day-two workflows that are awkward to handle through raw APIs alone.
Community and Evaluation users can operate a lot through APIs, SDKs, config files, and CLI workflows. The portal becomes important when AxonFlow moves from a single-team pilot into shared internal infrastructure.
What The Portal Is For
The portal is not a replacement for the Agent, Orchestrator, SDKs, or MCP connectors. It sits above them as an enterprise control surface.
| Area | What the portal helps with | Why it matters |
|---|---|---|
| License and deployment visibility | See tier, status, deployment mode, and capacity signals | Teams can tell whether they are looking at SaaS, self-hosted, or In-VPC behavior before debugging |
| Usage and analytics | Review request volume, token usage, cost trends, and exportable usage data | Finance, platform, and engineering can discuss real runtime usage from the same evidence |
| API keys | Create, scope, review, and revoke portal API keys | Internal automation can use narrow credentials instead of shared human sessions |
| Executions | Inspect MAP plans and WCP workflow runs in one operational view | Engineers can see failed, pending, approval-blocked, and completed work without stitching logs together |
| Approvals | Review require_approval decisions and paused workflow steps | Risk and compliance reviewers get a real queue rather than ad hoc scripts |
| SSO and identity settings | Configure organization sign-in and enterprise identity behavior | Security teams can align AxonFlow with corporate access controls |
| Provider and connector operations | Manage runtime provider and connector configuration where enabled | Teams can govern how AI systems reach models and downstream tools |
| Deployment operations | Trigger and track upgrade workflows where deployment mode allows it | In-VPC teams can coordinate controlled rollout without treating upgrades as hidden infrastructure work |
| Protected docs access | Grant and revoke access to protected implementation docs | Onboarding and role changes can be handled without broad manual sharing |
Authentication Model
The regular Customer Portal uses session-backed authentication. Users sign in through portal auth or enterprise SSO, and the portal then accesses protected /api/v1/* surfaces on behalf of the authenticated organization context.
This is intentionally separate from other credential types:
| Credential type | Best use |
|---|---|
| Portal session | Human users working in the Customer Portal |
| Portal API key | Narrow automation around protected portal workflows |
| SCIM bearer token | Identity-provider provisioning and group sync |
| Runtime client credentials | Agent and Orchestrator request paths |
| Admin API auth | Organization lifecycle and administrative operations |
Mixing these models is a common source of rollout friction. For example, a SCIM token should not be treated as a general portal automation key, and a portal API key should not be treated as a runtime client credential.
Deployment-Mode Awareness
The same portal adapts to the deployment it is operating against.
SaaS
In SaaS mode, the portal emphasizes tenant-scoped operations:
- usage and cost visibility
- keys and protected operational access
- policies, providers, connectors, and governed workflow review
- SSO and organization settings where enabled
Infrastructure-level node controls are intentionally limited because AxonFlow operates the infrastructure layer.
Self-Hosted And In-VPC
In self-hosted and In-VPC deployments, the portal can become more infrastructure-aware:
- deployment configuration
- upgrade status
- node and capacity visibility when enabled
- provider, connector, and runtime configuration tied to the customer's own environment
That difference is important for procurement and platform teams. A SaaS tenant and an In-VPC deployment should not expose the same operational controls.
Execution Review
Enterprise teams often run both MAP and WCP patterns:
- MAP for dynamic multi-agent planning
- WCP for deterministic workflow control, retry, idempotency, and per-tool governance
The portal's execution view is designed to put those runs in one operational frame. A reviewer should be able to answer:
- what ran
- which step is active or failed
- whether the run is waiting for approval
- what the cost and latency shape looks like
- which workflow style produced the execution
For implementation-level context, pair this page with Execution Viewer and Execution Operations Playbook.
Approval Review
The approval queue is the portal side of AxonFlow's human-in-the-loop model.
The healthy pattern is:
- Policy or workflow logic decides an action needs review.
- The workflow pauses instead of continuing automatically.
- A reviewer approves or rejects with context.
- The decision becomes part of the execution and audit record.
This is useful for regulated workflows, privileged connector actions, customer-impacting responses, and code or data operations where "allow" and "block" are not enough.
API Key Lifecycle
Portal API keys are for protected enterprise automation around portal workflows. A clean key process should include:
- descriptive names
- minimal scopes
- expiration where possible
- one-time handling of the secret value
- last-used review
- revocation when ownership or integration scope changes
These keys are separate from organization licenses, runtime client credentials, and SCIM tokens.
Usage, Export, And Review Workflows
The portal helps cross-functional teams answer practical questions:
- Is usage growing because adoption is increasing, or because one workflow is looping?
- Which provider or connector path is driving cost?
- Which requests failed, blocked, or required approval?
- What evidence can be exported for an internal review?
- Which teams need protected-doc access before rollout?
That is why the portal matters commercially. It makes AxonFlow easier for a broader organization to trust, not just easier for one engineer to operate.
What Stays In Protected Docs
The public page should explain the operating model. The protected docs contain:
- exact portal route behavior and response shapes
- deployment-specific setup
- customer-specific access patterns
- screenshots and environment-specific runbooks
- internal escalation and support workflows
Keeping that split clean lets public docs help technical buyers and LLM/search agents understand the enterprise surface without leaking customer-specific implementation details.
Upgrade Signals
The portal usually becomes a serious requirement when:
- more than one team uses AxonFlow
- reviewers need a queue rather than Slack or spreadsheets
- security wants SSO, SCIM, and controlled docs access
- platform teams need usage, cost, and execution visibility
- enterprise deployment controls matter for In-VPC or self-hosted rollout
- compliance teams need repeatable evidence review instead of log archaeology
At that point, AxonFlow is no longer just a runtime library. It is becoming shared AI infrastructure.
Related Docs
- Enterprise Overview
- Policy Management
- Human in the Loop
- Execution Viewer
- Execution Operations Playbook
- Identity Overview
- Community vs Evaluation vs Enterprise
Already a licensed customer? Use your partner pack or support channel for environment-specific setup details that should not be published in public docs.
