Governance Boundaries

Optimizely Opal in CMS 12 (PaaS) is delivered as a managed AI capability integrated into the authoring interface. While installation and UI verification confirm availability, operational clarity requires an understanding of what Opal explicitly does and does not change within the CMS architecture.

This page consolidates the documented constraints and platform requirements associated with Opal in CMS 12. The objective is to define clear operational boundaries without extending beyond officially supported behavior.

1. DXP-Only Availability

Opal Chat for CMS 12 is available only in Optimizely Digital Experience Platform (DXP) environments. Self-hosted or non-DXP CMS 12 deployments are not supported for Opal integration. This constraint has architectural implications:

• Infrastructure hosting for AI services is platform-managed.
• Availability and scaling are controlled by Optimizely.
• Feature activation depends on tenant provisioning within DXP.

Because Opal is a DXP-bound capability, enabling it requires both code-level installation and platform-level provisioning.

2. Tenant Provisioning Requirement

Successful NuGet installation does not automatically enable Opal. The organization must be provisioned for Opal at the tenant level. If Opal is installed but not provisioned, the UI entry point may not appear even though the package is present in the deployment artifact.

Operationally, this means:

• Code deployment and tenant enablement are independent steps.
• Verification must include confirmation of provisioning status.
• Environment-specific behavior may reflect tenant configuration rather than code differences.

3. Opti ID Dependency

Opal relies on Opti ID for identity management. The CMS instance must be configured to use Opti ID authentication. If Opti ID is disabled or misconfigured, Opal may fail to initialize correctly even if the add-on is deployed and provisioned.

4. Browser Policy Requirements

Opal’s interface experience may depend on browser behavior related to third-party cookies or embedded content policies. In environments where strict browser policies are enforced, Opal may not load as expected. Browser compatibility should be validated alongside deployment.

5. No Modification of Rendering Pipeline

Opal does not modify the CMS rendering pipeline. It does not:

• Alter Razor controllers or views.
• Transform stored HTML automatically.
• Inject rendering-time logic into templates.
• Change headless serialization behavior.

Content generated with Opal becomes standard CMS content once saved. It flows through versioning, approval, and publishing workflows exactly as manually authored content would.

6. Version Compatibility Constraints

The Opal add-on package declares compatibility boundaries with CMS UI versions. For CMS 12, the Opal Chat package specifies a supported range for EPiServer.CMS.UI.

• CMS UI versions must remain within the declared compatibility range.
• Major CMS upgrades require revalidation of Opal compatibility.
• Package updates should be reviewed for dependency changes before promotion.

7. No Automatic Publishing or Workflow Bypass

Opal provides content suggestions and drafting assistance. It does not automatically publish content, bypass approval workflows, or override role permissions. All standard CMS lifecycle controls (versioning, approval, scheduling, and access restrictions) remain in effect.

Conclusion

Opal in CMS 12 (PaaS) operates within clearly defined operational boundaries. It is DXP-only, tenant-provisioned, Opti ID-dependent, and subject to browser policy constraints. It does not alter the rendering pipeline, bypass workflows, or change content lifecycle mechanics. This ensures that Opal enablement remains predictable and aligned with platform expectations.