Key Concepts

The enterprise module provides the capability to make catalog and/or content changes outside the context of "production", preview the changes, and then promote/approve/deploy those changes to production.

Enterperise Approval Workflow

The basic flow for making data changes and deploying those changes is straight forward. Once a change is made, the change can be promoted (for approval), approved, and subsequently deployed.

Likewise, there are options after an initial save, after a promotion, and even after an approval to "revert" the changes and demote the change back to the previous state.

Sandboxes

The Enterprise module introduces the concept of Sandboxes. Sandboxes are the means to isolate changes within a context outside the "production" state. Each user upon making a change to a sandboxable entity will be making that change in their default user sandbox. Each user has a default sandbox where their changes will be associated.

Once a change is promoted, that change is moved to an approval sandbox. From the approval sandbox, the change can be approved and then scheduled for deployment.

Data Management within Sandboxes

As the approval workflow executes, each step of the workflow (change, promote, approve, deploy) is tracked in the workflow sandbox tables and recorded as new "sandbox" entries in the related entity table.

The workflow sandbox tables track what entity has been changed, what sandbox contains the changes, the specific properties/values that changed, and promotions/approvals that have been conducted as a set (i.e. changeset). See the Enterprise module data model for additional information on these tables. This document will not outline the specifics of the tables nor their individual purpose.

The entity "sandbox" entries are new rows inserted into the entity tables as the workflow executes. Each entry contains the sandbox where the change is associated, the associated change, and the "tier" (progression) within the workflow. These entries are actually created from a "replay" process that is driven by the data in the workflow sandbox tables. You will see the following rows:

1) "production" row - this is the row that is currently in production or will be once deployed (if a new row). This row will have a "NULL" SNDBX_ID value and a "NULL" SNDBX_TIER value.
2) "tier 1" row - this is the row created when an initial change is saved. It will have an associated SNDBX_ID and a SNDBX_TIER value of "1".
3) "tier 2" row - this is the row created when a change is promoted. This represents changes that are pending approval. This row will have a SNDBX_ID and a SNDBX_TIER value of "2"

As the workflow progresses, previous rows will be archived. For example, once a promotion is executed, the "tier 2" row will be created (as outlined above) and the "tier 1" row will be archived - since it is no longer needed.

Retaining the Original ID

The flow is designed to support the isolated sandbox concept but also retain the original ID of the "produciton" row. This ensures consistency of that ID for referential integrity purposes.

Extending Sandboxable Entities

When sandboxable entities are extended (with Joined Inheritance Strategy), the extension table will also participate in the sandbox "replay" process and additional rows will be present in those table.

Data Clean Up

There is an out-of-box process that can be setup as a scheduled job to maintain both the Workflow Sandbox tables as well as the sandbox rows created in the entities. This job will periodically purge the archived rows keeping those tables trimmed and clean.