Skip to main content

Enterprise Rollout Checklist

Enterprise rollout is not only a bigger deployment. It is the point where AxonFlow becomes shared internal infrastructure with platform teams, reviewers, and governance stakeholders around it.

This checklist is designed for the engineer or platform owner coordinating that transition.

1. Platform Ownership​

Confirm:

  • which team owns the AxonFlow deployment
  • who owns policies, connectors, and provider configuration
  • who owns incident response for workflow failures or blocked approvals
  • which stakeholders need read-only versus admin access

Without clear ownership, enterprise features often exist but still get run like a side project.

2. Identity And Access​

Before broad rollout, confirm:

  • SSO provider choice
  • SCIM or manual provisioning model
  • role mapping for platform teams, approvers, reviewers, and auditors
  • which environments require enterprise access versus developer access only

This is where Enterprise starts to differ sharply from Community and Evaluation. Identity is part of the operating model, not just login plumbing.

3. Governance Design​

Confirm:

  • which system policies are global guardrails
  • which tenant policies belong to each application or business unit
  • where require_approval is expected
  • who signs off on policy changes and simulations
  • which evidence and export requirements apply

Use Policy Simulation and Evidence Export as part of this rollout design, not as afterthoughts.

4. Connector And Provider Strategy​

Confirm:

  • which LLM providers are allowed in each environment
  • which connectors are portal-managed versus runtime-managed
  • whether enterprise connectors are part of the initial rollout
  • how cost and token visibility will be reviewed

This step is often where teams realize they are not only adopting a runtime. They are adopting a governed integration layer across providers and data systems.

5. Approval And Exception Operations​

Confirm:

  • which workflows can pause for review
  • who approves or rejects steps
  • what happens on expiry
  • whether break-glass overrides are allowed and by whom
  • how pending approvals will be monitored and escalated

If the team cannot answer these clearly, the approval surface will become a source of operational drag.

6. Execution Operations​

Confirm:

  • who monitors execution health
  • which dashboards or alerts are required
  • how execution replay and export are used during incidents
  • whether the portal execution views and unified execution APIs are part of the platform workflow

Enterprise rollout should make Execution Viewer and the surrounding execution APIs part of day-two readiness, not just engineering knowledge.

7. Compliance And Audit Expectations​

Confirm:

  • required retention expectations
  • whether regulated workflow modules are in scope
  • who needs audit exports or evidence packs
  • which control narratives security or procurement will ask for

This is often the moment where Enterprise is justified not by traffic volume, but by governance expectations.

8. Deployment Model​

Confirm:

  • SaaS versus In-VPC deployment model
  • network, secret management, and environment ownership
  • production readiness checks for failover, monitoring, and upgrade paths

This is also the right moment to align Deployment Mode Matrix and Capacity Planning And Sizing with the rollout.

9. Rollout Decision​

By the end of the checklist, you should be able to say one of three things clearly:

  • Community is still enough for now
  • Evaluation is enough for the pilot we actually plan to run
  • Enterprise is the correct landing zone because the operating model already requires it

The strongest enterprise rollouts happen when that decision is explicit and documented rather than implied.

Contact [email protected] or deploy via AWS Marketplace.

Enterprise Quick Start​

Use this quick start after an enterprise environment exists and the team needs to verify portal access, auth, health, connectors, providers, governance, monitoring, and onboarding order.

This quick start is for enterprise customers who already have access to the enterprise docs and want to get from “we received our environment” to “our platform teams and engineers can actually use it” quickly and cleanly.

The aim is not only to deploy infrastructure. It is to confirm that the portal, session authentication, provider configuration, connectors, monitoring, and enterprise APIs are all usable for a real team.

What You Need Before You Start​

Have these ready:

  • access to your AxonFlow enterprise environment
  • your organization ID and portal password, or SSO-enabled tenant configuration
  • the deployment endpoint or domain provided for your environment
  • access to the customer portal
  • the internal owner who can configure providers, connectors, and deployment settings

Depending on your deployment model, you may also need AWS access for deployment or upgrade operations.

Step 1: Verify Portal Access​

The customer portal is the operational entry point for many enterprise features.

Use the portal login flow first:

  1. open your customer portal URL
  2. sign in with organization credentials or SSO
  3. confirm that you can reach the dashboard after login

If you are validating from the API side, the portal login endpoint is:

POST /api/v1/auth/login

That endpoint creates the axonflow_session cookie used by portal-backed APIs.

For runtime API calls that use Basic auth (e.g., agent health checks), the credential format is:

curl -sf http://YOUR_AGENT_HOST:8080/health \
  -H "Authorization: Basic $(echo -n 'your-client-id:your-client-secret' | base64)"

Step 2: Confirm Session Authentication Works​

The portal exposes a session-check endpoint:

GET /api/v1/auth/session

That is the fastest way to confirm the portal session is active and recognized by the backend.

If your organization uses SSO, also verify the SSO availability check:

GET /api/v1/auth/sso/availability?org_id=YOUR_ORG_ID

This tells you whether SSO is configured and whether password login should still be available.

Step 3: Verify Deployment Mode and Health​

Before touching policies or connectors, confirm the environment itself is healthy.

Useful checks:

curl -sf https://YOUR_PORTAL_OR_EDGE_ENDPOINT/health
curl -sf https://YOUR_PORTAL_OR_EDGE_ENDPOINT/api/v1/deployment/config

What to confirm:

  • the enterprise environment responds cleanly
  • deployment config is exposed
  • the portal can authenticate users
  • the underlying Agent and Orchestrator are reachable through the enterprise deployment model

If this step is shaky, stop and use the Deployment Troubleshooting guide before onboarding users.

Step 4: Create or Review API Keys​

Portal-backed API key management is available once you are authenticated.

Enterprise platform teams usually do this early so automation and internal admin tooling do not depend only on browser sessions.

Relevant endpoints:

  • GET /api/v1/keys
  • POST /api/v1/keys
  • GET /api/v1/keys/{keyID}
  • DELETE /api/v1/keys/{keyID}

Use API keys for automation where that is appropriate, but keep in mind that some enterprise surfaces still rely on session-based or SCIM-specific auth models.

Step 5: Configure One Provider and One Connector​

Do not call the rollout complete until the platform can do both of these:

  • route one LLM-backed request successfully
  • reach one real connector-backed system successfully

The customer portal exposes configuration endpoints for:

  • GET/POST/PUT/DELETE /api/v1/llm-providers
  • PUT /api/v1/llm-providers/routing
  • GET/POST/PUT/DELETE /api/v1/connectors
  • POST /api/v1/connectors/{connectorName}/test

Recommended first validation:

  1. configure one provider your organization already uses
  2. configure one non-destructive connector integration
  3. test both from the portal or the enterprise API

This catches the real operational issues early: secrets, IAM, network reachability, routing, and policy behavior.

Step 6: Validate Policy and Governance Flows​

Enterprise rollout should include more than simple request success. Validate one governed workflow:

  • confirm that the portal can list and manage policies
  • confirm policy exports or tests work
  • confirm unified or enterprise policy views make sense for your tenant

Useful portal-backed endpoints include:

  • GET/POST /api/v1/policies
  • GET /api/v1/unified-policies
  • GET/POST /api/v1/static-policies
  • GET /api/v1/policy-categories

If your organization uses approvals, also validate the HITL path before wider rollout.

Step 7: Validate Monitoring and Audit Surfaces​

Platform Teams should verify observability before onboarding more users:

  • dashboard access
  • deployment and runtime health visibility
  • logs for providers, connectors, and portal actions
  • audit and usage surfaces

Start with:

Step 8: Decide What to Onboard Next​

Once the basics work, the next enterprise step usually falls into one of these tracks:

  • identity and provisioning: set up SSO and SCIM
  • governance and approvals: set up policy workflows, approvals, and oversight
  • regulated deployment: align to EU AI Act, RBI, SEBI, MAS FEAT, or internal review needs
  • operations and scale: set up deployment upgrade flow, dashboards, alerts, and runbooks
Last updated on