Skip to main content

Environment Readiness

Environment readiness confirms that the customer environment can support configuration, integration, validation, and production operations. It prevents late-stage blockers such as missing domains, network routes, certificates, source-system owners, or approval paths.

Prerequisites​

Complete the deployment model decision first. Assign a customer environment owner, customer IT owner, DataMesh project owner, business owner, and support owner before configuration work starts.

Readiness flow​

Inputs​

Readiness areaRequired input
EnvironmentDeployment model, region, domain, environment URL, staging or validation path.
IdentityIdP owner, sign-in method, test users, admin users, role model, SSO metadata if needed.
NetworkSource-system routes, firewall rules, proxy rules, allowlists, DNS, certificate owner.
DataSource-system owners, sample data, asset identifiers, document samples, data-quality expectations.
IntegrationService identities, API scopes, connector credentials process, schedule expectations.
OperationsSupport contacts, incident path, maintenance window, monitoring expectations, backup owner.
SecurityData classification, retention expectations, audit needs, approval requirements.

Preparation steps​

  1. Confirm the environment name, URL, deployment model, and production boundary.
  2. Create or confirm tenant administrators and project administrators.
  3. Prepare SSO or password-login test accounts.
  4. Confirm network routes from FactVerse to required source systems and from user devices to FactVerse.
  5. Prepare certificates, domains, DNS records, and proxy rules where required.
  6. Prepare sample source data, documents, assets, and workflow scenarios for validation.
  7. Confirm backup, monitoring, maintenance window, and escalation ownership.
  8. Record open blockers with owner and target date.

Validation checklist​

  • Users can reach the environment URL from the expected network.
  • Administrators can sign in and access the target tenant.
  • SSO or password-login test users are available.
  • Source-system connectivity has an owner and test method.
  • Sample data and documents are available for configuration validation.
  • Service identities and API scopes have been requested or prepared.
  • Support contacts and escalation path are documented.
  • Backup and maintenance expectations are approved.

Readiness evidence​

Keep readiness evidence lightweight and reviewable. A good readiness record usually includes the deployment decision, tenant and administrator confirmation, identity test result, network route confirmation, certificate owner, sample data location, source-system owner list, connector credential process, support contact list, maintenance window, and unresolved blocker register. For regulated or high-control environments, attach the approval record or change ticket used by the customer IT team.

This evidence should be collected before configuration work becomes dependent on a single person. If an implementation team changes or a production incident occurs later, the readiness record helps the next owner understand what was agreed, which routes and accounts were prepared, and which dependencies still need customer approval.

Expected result​

The environment is ready when the project team can configure FactVerse, connect required sources, validate identity, run pilot workflows, and collect acceptance evidence without waiting for missing infrastructure or ownership decisions.

Troubleshooting readiness gaps​

SymptomCheck
Users cannot open the environmentDNS, certificate, proxy, VPN, firewall, or domain approval.
SSO test cannot startIdP owner, metadata, callback URL, application assignment, or test account.
Connector setup is blockedSource owner, credential path, endpoint route, sample data, or allowlist.
Administrators see the wrong tenantEnvironment URL, tenant mapping, account invitation, or project membership.
Go-live date is at riskOpen blocker owner, acceptance scope, change approval, or data readiness.