The Tenant Manager in Assette simplifies the process of moving content between tenants by intelligently comparing artifact versions and automatically managing dependencies. The Tenant Manager includes version-aware metadata tracking and a guided artifact review process. This process of cross-checking artifacts occurs in the “Review Artifacts” step of a deployment.
Automatic Dependency Inclusion #
If you select a Smart Page, associated components such as Smart Shells and Data Objects are automatically included. By default, all dependencies are selected to ensure a complete and functional deployment. This helps you avoid missing related components and ensures consistency across tenants.
Intelligent Version Comparison #
The first time an artifact is deployed, the Tenant Manager compares the artifact versions in the source and target tenants based solely on their content. Since no historical metadata exists between the two tenants at first, all differences are treated as updates in both environments. Upon deployment, the system updates metadata. For all subsequent deployments, the Tenant Manager compares the current version of each artifact to the version metadata in the target tenant. This ensures a more accurate version comparison and reduces conflicts.
This Assette Tenant Manager Deployment Flow diagram illustrates how artifacts are versioned and deployed between two tenants—Source and Target—using a version mapping system maintained by a metadata service. The process is broken down into three phases: initial deployment, independent versioning, and a second deployment based on version alignment logic.
In Phase I, a user in the Source tenant creates and saves an artifact multiple times, resulting in incremental major and minor versions (e.g., v1.0, v1.1, … v3.0, etc.). The artifact then is copied from the Source to the Target tenant via the Tenant Manager. When this occurs, the Target tenant treats the artifact as a new artifact and begins its own versioning at v1.0. The system then stores a mapping between Source and Target version in the metadata store, establishing the initial relationship between the two tenants’ versions.
In Phase II, users in both the Source and Target tenants continue to make changes independently. These changes occur separately, with no direct synchronization between the tenants, allowing each to evolve their artifact versions based on their own workflows.
During Phase III, a second deployment from Source to Target is initiated. The system first consults the stored metadata to identify the last common version mapping, which is Source v3.0 mapped to Target v1.0. Since the Target tenant has progressed to v2.0 independently, the system computes the next appropriate version as v3.0 for the incoming artifact. The Source artifact at version v4.0 is then copied to the Target tenant and registered as version v3.0. Finally, the metadata is updated to reflect this new mapping between Source v4.0 and Target v3.0.
Deployment Review Tabs #
To help users easily track changes, the Artifact Review screen organizes artifacts into five informative tabs:
| Tab | Description |
|---|---|
| All | Displays all artifacts selected for deployment, regardless of status. |
| New in Source | Artifacts that exist only in the source tenant and will be created in the target. |
| Updated in Both | Artifacts modified in both environments. Deploying will overwrite the version in the target. |
| Updated in Target | Artifacts modified in the target tenant only. Deploying will overwrite the target version. |
| Updated in Source | Artifacts changed in the source tenant only. Deploying will update the target. |
Best Practices #
- Always review dependencies and tabs before finalizing deployment.
- Use the version comparison history to understand why an artifact is marked as changed.
- Trust the metadata: It ensures that your deployment logic gets more accurate over time.
This enhanced deployment process in the Tenant Manager ensures greater control, accuracy, and visibility—making your environment management smoother and smarter.