Enterprise controls Identity, audit, deployment, support

Enterprise.
Identity, access, deployment, and evidence.

Name the caller, scope the access, record the result.

ERP.AI separates organization identity, roles, app access, audit records, and deployment configuration. Contract terms define service levels, support, compliance scope, and any dedicated infrastructure.

Contact sales Open the map
An enterprise, assembled layer by layer A crane transfers detailed prefab floors from the left stack to the right building. Trolley wheels and a cable drum turn during transfer, crane beacons pulse, and the receiving foundation signals each landing. A small dark service stack anchors the scene.
Users and app roles are named Audit records stay queryable Deployment terms are contract-defined
Control map Policy path Deployment Operations
Control map Product path

See the checks
around a protected change.

Enterprise control starts with the account, checks its role and app access, limits where the change may run, and keeps a record of the result.

Control sequence Identity → access → change → record Product path
Identity User or service account

The platform resolves the account and organization first.

Requested change App operation

The request identifies the app, record, and intended change.

Access check Role and permission

The change continues only when the account has the required access.

Deployment target Allowed app and environment

The change stays inside the selected organization, app, and deployment.

Evidence return identity policy decision record change deployment target support route
Policy path Four control questions

One policy path,
four control questions.

The page follows the same action from request to evidence instead of presenting identity, security, governance, and support as interchangeable feature cards.

Who is acting?

Identity and access

Users, service accounts, directory connections, and role assignments establish the account.

Resolve before action
May it proceed?

Policy and approval

Role, resource, environment, and human-review requirements determine whether the change moves.

Hold when unclear
Where may it run?

Deployment boundary

Tenancy, network isolation, region, and secret access define the permitted target.

Constrain the runtime
What remains?

Evidence and response

Caller, decision, change, result, and escalation route remain available in the owning service.

Keep the record
Deployment Operating models

Choose the boundary
that matches the operating model.

The product repositories support shared and dedicated deployment patterns. The actual boundary, ownership, service level, and compliance scope must be confirmed in the contract.

ModelRuntime boundaryCustomer controlOperations
Shared SaaS Multi-tenant platform Identity, policy, exports ERP.AI operated
Isolated runtime Dedicated network and compute, if contracted Network, identity, deployment policy Jointly governed
Dedicated instance Single-tenant application and data, if contracted Region, keys, access, release gates Contract-defined

Certification coverage, availability commitments, recovery objectives, and response targets are confirmed in the applicable order form and service documentation.

Operations Ownership and handoff

When a control fires,
the owner is already named.

User, account, workflow, and deployment events can feed incident, change, release, and review work. The owning service determines which details are available.

Contact sales Review pricing
Incident
Severity, impact, owner, response, follow-up
Change
Risk, approval, release window, rollback state
Security
Principal, event, policy result, export destination
Review
Open decisions, capacity, exceptions, roadmap owner
Enterprise Confirm product and contract scope

Map the identity
before granting access.

Review roles, app boundaries, audit coverage, deployment ownership, and contract terms.