Skip to content

Admin console

The admin console is the single, coherent surface where a Tenant Admin runs the Venturi tenant: users and their lifecycle, identity (SSO, SCIM, and MFA), access policy, recertification, credentials, tenant settings, and billing visibility. Every control shows its current state and its safe default, every mutation writes an append-only audit entry, and every denial names the factor that caused it: never a generic error and never a “degraded” banner used to mask an access decision. No control here runs in the decision-time interceptor’s request path; administrative actions are fail-closed, never fail-open.

Where it lives

The console is Settings / Admin, under Settings in the app’s Platform section. Its destinations are Users, Identity (SSO and SCIM), Roles, Integrations / Connectors, Security, Credentials, Notifications, Billing, and Audit log. They are reachable to users holding the Admin role. A non-admin who reaches an admin route sees a clear permission denial naming the role required, not a broken page.

Where each control lives

This table is the reference for administration paths across these docs. Each path is the breadcrumb the app shows, with / separating each level.

Path What you manage there
Settings / Admin / Users Invitations, manual provisioning, suspension, deactivation, ownership transfer, and offboarding
Settings / Admin / Identity The identity panel: MFA policy plus the SSO and SCIM connections below, each with its default and current state
Settings / Admin / Identity / SSO SAML 2.0 or OIDC connection, domain claims, IdP group-to-role mapping, the connection test, and SSO-only enforcement
Settings / Admin / Identity / SCIM SCIM enablement, the SCIM base URL and bearer-token issue, the connection test, the JIT provisioning toggle, and IdP reconciliation findings with the orphan threshold
Settings / Admin / Roles Canonical and custom roles, scoped grants, explain access, delegation, impersonation, and recertification campaigns
Integrations / <Connector name> Setup, Test connection, and health for each source-system connector (also open to users with connector settings access)
Settings / Admin / Security Session and password policy, residency and classification posture, the minimum cohort size for workforce and adoption reporting, retention overrides, and support-access (break-glass) requests
Settings / Admin / Credentials The credential rotation panel: SCIM bearer tokens, API keys, SSO client secrets and signing keys, webhook signing secrets, and connector credential references
Settings / Admin / Notifications Routing for budget, alert, and security notifications: in-app, email, Slack, Microsoft Teams, and signed webhook
Settings / Admin / Billing Plan entitlements and consumption on the billing entitlement card (read-only for FinOps)
Settings / Admin / Audit log The audit-log viewer: filter, investigate, and export your tenant’s audit trail

Every destination under Admin requires the Admin role, with three exceptions:

  • Billing visibility. A FinOps user, or any user whose grant includes billing visibility, can open Settings / Admin / Billing read-only to view plan entitlements and consumption. Changing the plan or billing settings stays Admin-only and requires a fresh step-up assertion.
  • Connector settings access. A user granted connector settings access, such as an Engineer who registers sources, can open Integrations to set up, test, and monitor connectors.
  • Auditor grant. An Auditor grant opens Settings / Admin / Audit log read-only for the length of its time box.

Any other user who reaches an admin route sees a clear permission denial naming the role required, not a broken page.

Your plan

Your plan is the commercial subscription named on your order form: its included quantities, feature entitlements, and contractual ceilings. It sets the role and feature ceiling that custom roles and IdP group mappings resolve against, and the default API rate limit for each route class. Settings / Admin / Billing shows the active plan entitlements and consumption. Your plan is separate from your support tier (Standard, Premium, or Regulated), which sets support response targets and the commitments in SLAs & SLOs.

What you manage here

  • Users & lifecycle

    Invite, provision, suspend, deactivate, and transfer ownership, with each grant showing its effective scope path and least-privilege flags. Path: Settings / Admin / Users. Recertification campaigns run at Settings / Admin / Roles.

  • Identity

    SSO configuration and group mapping, SCIM enablement, MFA policy, domain claiming, and the JIT toggle, all under Settings / Admin / Identity with defaults visible.

  • Access policy

    Roles, custom roles, separation-of-duties visibility, delegation and impersonation controls, and access recertification campaigns at Settings / Admin / Roles. See Roles & access control.

  • Credentials

    Inventory, expiry, and rotation for every credential the tenant holds, at Settings / Admin / Credentials. See Credentials you manage.

  • Tenant settings

    Session duration and idle timeout, password complexity, residency and classification posture, the minimum cohort size, retention, notification routing, and configuration precedence, at Settings / Admin / Security and Settings / Admin / Notifications.

  • Usage & billing visibility

    Plan entitlements and consumption on the billing entitlement card at Settings / Admin / Billing. Billing visibility extends beyond Admin: FinOps users view the card read-only. Billing mutation is fail-closed, Admin-only, and requires a fresh step-up assertion.

  • Support access

    Approve, time-box, scope, and revoke Venturi support break-glass sessions at Settings / Admin / Security, or leave them off. Venturi has no standing access.

User lifecycle

The console drives the full account lifecycle at Settings / Admin / Users. Every transition is an explicit, audited action with a safe failure mode:

Stage What happens Safety mode
Invite Admin invites by email with an initial role and scope; no self-registration Single-use, expiring invite; fail-closed if expired
Provision (manual) Invited user registers with a method allowed by tenant policy Unverified email cannot activate
Provision (SCIM/JIT) Users and groups flow from your IdP; JIT assigns mapped grants, or zero grants until admin assignment Deprovision revokes sessions and resolves grants to deny within the SCIM sync SLA: 60 seconds by default, 300 seconds at most
Activate Account becomes usable; first session subject to MFA policy MFA enforced where policy requires
Suspend Temporarily block authentication without deleting history Active sessions revoked server-side immediately
Deactivate Disable the account; audit history preserved Cannot authenticate; grants resolve to deny
Transfer ownership Reassign objects/teams/projects/connectors a departing user held Orphaned objects never silently lose an owner; transfer audited
Offboard Revoke all grants; SCIM-driven where federated; personal data crypto-shredded within 30 days of an erasure request Fail-closed; audit trail persists pseudonymized
Recertify Attestation of remaining access on the campaign schedule and due date you set at Settings / Admin / Roles Stale grants default to restricted, not retained

See Roles & access control for how scope, attributes, and separation of duties shape each grant.

Identity, on one surface

The identity panel at Settings / Admin / Identity brings every identity control together with its security-relevant default already chosen and its current state shown:

Validation before activation

SSO-only and SCIM provisioning are validation-first. Neither can be switched on until its connection test passes (see SSO and SCIM), and the panel shows each control’s live state rather than its configured intent.

Control Default Effect when changed
SSO-only On for enterprise tenants after verified federation Rejects non-exempt password, passkey-only, and social sign-in with SSO_REQUIRED; revokes non-exempt non-SSO sessions at next validation
SCIM Off IdP-driven create/deprovision within the sync SLA; group→role mappings resolve to scoped grants
MFA Enforceable tenant-wide or per role Users in scope present a second factor at sign-in; step-up for sensitive operations stays on regardless of this setting
Domain claiming None claimed Verified domains enable JIT and assert tenant membership
JIT provisioning Off; mapped grants or zero grants when on First SSO login on a verified domain creates an account; unmatched users need an administrator to assign a role before access

Before federation cutover, an invitation-bound bootstrap administrator can use local password or passkey authentication. After cutover, the only local-access exception is an explicitly enumerated break-glass administrator protected by MFA, step-up, independent audit, and periodic recovery testing. Social sign-in is disabled by default and requires tenant-admin opt-in for eligible non-enterprise deployments; it never bypasses enterprise SSO-only enforcement.

Every change to any of these is a fail-closed authentication/authorization change (never fail-open) and writes an append-only audit entry.

Credentials you manage

Cloud onboarding uses no long-lived cloud credentials by default: AWS access runs on cross-account role assumption, and Google Cloud and Azure access run on workload identity federation (see Trust & security). The credentials a Tenant Admin does manage are inventoried at Settings / Admin / Credentials, each with its expiry and rotation state:

  • SCIM bearer token. Long-lived until rotated. Rotation issues a new token, and the old one keeps working until the overlap window shown in the panel closes, so your IdP never loses provisioning access mid-change.
  • Venturi API keys. Long-lived until rotated or revoked. Scope each key to the narrowest permission set and rotate it on your schedule; see API keys.
  • SSO client secrets and signing keys. The OIDC client secret you paste and the SAML signing and encryption keys rotate with an overlap window; during a SAML key rotation both certificates are published in the SP metadata.
  • Webhook signing secrets and SaaS connector credentials. Held encrypted in your tenant’s credential store; the webhook or connector that uses one holds only a reference to it. During a webhook signing-secret rotation, deliveries carry signatures under both the outgoing and incoming secrets until the overlap window closes (see Secret rotation). Rotate connector credentials per the vendor’s guidance.
  • Azure client-secret fallback. Present only where your Azure onboarding uses it instead of federation. It carries a 90-day TTL, is stored in your Terraform state (protect that state), and reaches Venturi only through the encrypted handoff path; see Rotate & offboard.

Authentication secrets (SCIM bearer-token hashes, API-key hashes, OIDC client secrets, and SAML private keys) are stored encrypted under your tenant’s KMS key and are never written in plaintext or to logs. Creating or rotating a credential requires a fresh step-up assertion and writes an audit entry.

Tenant settings

Tenant settings let you tune the tenant to your organization’s policy. Session, password, residency, minimum cohort size, and retention settings live at Settings / Admin / Security; notification routing lives at Settings / Admin / Notifications. Settings resolve with a clear precedence (tenant override > workspace override > platform default), and every effective value is auditable with its source layer shown:

  • Sessions: the idle timeout defaults to 30 minutes (configurable from 5 minutes to 8 hours) and the absolute session lifetime defaults to 12 hours (configurable from 1 to 24 hours). Admins can also force session revocation.
  • Password complexity: enforced complexity and account lockout for the password method, while that method is enabled (SSO-only disables it for non-exempt users).
  • Residency & classification posture: view and confirm your tenant’s residency lane and data-classification policy. Residency routing is fail-closed: a request that would touch an out-of-lane resource is blocked, not served cross-border.
  • Minimum cohort size: defaults to 5. Workforce and adoption reporting suppresses any smaller cohort and rolls it into its parent unit. You can raise the minimum above 5; no setting, role, or custom role can lower it below 5. See Roles & access control.
  • Retention: operational data defaults to 13 months and is configurable per data class from 30 days to 5 years; the configured value governs deletion eligibility. The audit trail is retained separately, for 5 years under Object Lock.
  • Notification routing: where budget, alert, and security notifications are delivered (in-app, email, Slack, Microsoft Teams, signed webhook).

Support access (break-glass)

Venturi support has no standing access to your tenant. Diagnostic access exists only through a customer-approved, time-boxed, scoped, audited break-glass workflow that you control entirely at Settings / Admin / Security:

No access unless every check passes

Support receives no tenant-data access unless the approval, time-box, scope, MFA, tenant and residency binding, and audit checks below all pass for that session; a failure at any check denies the session. Without an approved session, support works from diagnostics you supply.

Property Behavior
Request Support raises a request naming the tenant, the narrowest data class, and the reason
Approval No access exists until your admin approves; approval is required, not bypassable
Time-box Every session carries a hard expiry (4 hours by default, never more than 24 hours) and auto-expires; extending it requires a new approval
Scope & mode Limited to the approved tenant and data class; read-only by default; write requires explicit elevation
Audit Every session and every action within it is written to your audit trail and notifies you
Revocation You can revoke at any time; revocation or expiry fails closed with no residual access

You watch and govern each session on its support case timeline. A break-glass session can never cross your tenant boundary. See Support-access architecture for the full flow.

Implementation checklist

For tenants still onboarding, the console presents a single implementation checklist that mirrors the prerequisites and resolves each item against live state: read-only access grants, encryption-key provisioning, outbound-only egress, connector validation, coverage, your first chargeback-eligible export, and finance acceptance. These onboarding prerequisite items show real status as met, pending, or blocked, and each blocked item deep-links to the action that resolves it.

Identity and access controls use a separate verification vocabulary. The checklist records each one you enable (SSO, SCIM, MFA and step-up, roles and scopes, and support break-glass) as verified, pending, not enabled, or not applicable for your tenant. Current implementation status explains how that evidence relates to the customer-onboarding baseline.

The same contract on every control

For any lifecycle stage or policy control, the admin console shows the surface, shows current state, writes an append-only audit entry on mutation, and renders any denial with the determining factor named. Every administrative mutation is fail-closed; none inherits the decision-time interceptor’s fail-open behavior.

Next steps

Give feedback on this page

Sign in to send feedback. Opens in a new tab.

Copy page details 
Docs feedback: Admin console
Page: https://docs.venturi.systems/administration/admin-console/