Standard governance model for censhare Web
The standard governance model defines the way how the domain framework and user roles are set up to work together. Follow the new standard governance model to set up custom DAM, PIM and Content Management solutions for censhare Web.
Target groups
Solution developers, solution administrators
Context
The standard governance model comprises the domain framework to store your assets, and user roles to assign the necessary permissions.
The domain framework is implemented on the 1st domains tree. The 2nd domains tree can be freely configured. For example, for secondary units, branches or regions.
The user roles are designed to give users read and/or write access to their work domain and to the common resources domains.
The user configuration for default role/domain and additional roles/domains follows the domain framework and user roles setup of the standard governance model.
Prerequisites
To build your custom governance model, we recommend to use censhare Dedicated solutions as a blueprint. If you build your custom governance model from scratch, make sure that your domain framework is compliant with the censare Dedicated solutions framework!
Introduction
The new standard governance model for censhare Web is designed to meet three main objectives:
Separate the system, solution and production layers in the domain framework.
The domain framework can be adapted to organizational growth and changes without interfering with the system and solution layers.
Users and solution administrators have a dedicated, clean workspace where they can access exactly the assets they need for their work.
Important: The new standard governance model is mandatory for censhare Web solutions as of version 2019.3. To develop your own custom solution, make yourself familiar with the frameworks and principles of the new standard governance model.
Access layers
Concept
The access layers are an abstraction of the combined roles and domains model of censhare. Users, according to their role, access domains within the same layer.
From a user perspective, access permissions are inherited downwards in the domain tree, but not between sibling domains. Users can search and access assets in their domain and in child domains. This means, that in the user profiles, you must configure the default domain and additional domains for a user accordingly.
From an asset perspective, features (aka asset properties), asset files (XSL, XML, images, etc.) and master data can be accessed upwards in the domain tree. This means. All assets in the production domains can access these configurations in the Root and Solution administrationdomains.
Generic model
There are three access layers that are closely related to the user roles: System, Solution and Production. The following diagram shows the generic domain tree and the respective access layers.
Note that the depth of a domain in the domain tree does not always reflect the layer to which this domain belongs. For more information about the layer concept, read also the following sections:
Generic domain tree.
** Domains are only required in combination with an Online channel solution.
Your custom domains are added to the production layer (for example: brands, departments, production units). If necessary, you can add a solution administration domain that stores custom configurations (for example: resource replace variants to the workspace).
Dedicated solutions model
The following diagram shows how the new standard governance model is applied to the censhare dedicated solutions. For more information, see Domain frameworks for censhare dedicated solutions.
** Domains are only required in combination with an Online channel solution.
The workspace, workflows, roles, and the solutions for Digital Asset Management (DAM), Enterprise Content Management, and Product Information Management work seamlessly with this domain tree. Using censhare Dedicated solutions can save you a lot of effort to set up a custom system.
System layer
The system layer is reserved to system administrators. The system administrator role gives read/write access to the root domain.
The system layer comprises the Root domain. The Root domain contains all assets that are necessary to run the system (and the unique System asset itself), as well as the Workspace / ...assets that provide the user interface of censhare Web.
Add a hidden child domain to the Root domain to remove Master data definitions that are not needed in your solution. Thus, you can conveniently add these items in case you need them by moving them back to the Root domain.
All Feature definitions that are shipped with the censhare standard product are by default assigned to the Root domain. Features are stored and accessed as Asset properties or Asset relation properties. The permission to add and edit Asset properties and Asset relation properties is handled by the working domain of a user. Therefore, it is normally not necessary to move asset features to another domain.
All Asset type definitions that are shipped with the censhare standard product are by default assigned to the Root domain. This means that users can create any type of assets in their domain.
All Asset relation type definitions that are shipped with the censhare standard product are by default assigned to the root domain. To restrict the creation of asset relations, censhare uses filters in the asset relation type definitions. Therefore, it is not necessary to move asset features to another domain, even if they are used only in specific domains.
System administration is only partially carried out in censhare Web. For example: the System asset settings, widget configurations, transformations and scripts. To carry out their tasks, system administrators also require a censhare Admin Client and access to the censhare Server directory on the host server.
Solution layer
The solution layer is reserved for solution developers and solution administrators.
Solution developers can access the Solution administration domain to store solution-specific customizations and configurations:
- Transformations: XSL stylesheets that implement business logics, aggregate data outputs, etc.
- Macros: Functions that calculate, order or enrich properties that can be used in widgets.
- Workspace customizations: Resource replace variants of Module / Workspace / ... assets that modify the user interface of your solution.
Solution administrators can access the Common resources domain to create censhare Web resources that are required for the functionality of your solution, but do not need to be accessed directly by users:
- Feature assets: The asset representation of features (including product features in PIM solutions).
- Feature item assets: Feature items represent dedicated values of a feature.
- Keyword assets: Keywords can be assigned to your production assets.
- Category assets: Categories can be assigned to your production assets.
- Quality gate sequence assets: Quality gate sequences are used for the Quality management of your production assets.
- Quality gate assets: Used in quality gate sequences.
- Completeness check assets: Used in quality gates.
Do not store assets that store configurations of your solution (for example widget configurations) in the Common resources domain. These assets must be stored in the Solution administration domain. Otherwise, asset pages where the respective configurations are used do not work in the production domains, as these domains belong to a different branch.
Optionally, depending on your project design, the following assets can be stored in the Common resources domain:
- Product category assets: Product categories build the product classification in PIM solutions.
Common resources sub-domains
If your project design requires users to directly access some asset types in the Common resources domain, use a sub-domain: Common resources / Sub-domain.
- Assets that only provide data and functionality, but do not need to be accessed directly, remain in Common resources. For example: Feature assets.
- Assets that need to be accessible directly by users, are moved to Common resources / Sub-domain domain. For example: Keyword assets.
This governance model requires an adapted user configuration with a corresponding role that all users have in Common resources / Sub-domain.
Production layer
The production layer contains the default working domains of your regular users. Production assets are stored in the domains of the production layer. These domains can represent departments, production units or a dedicated solution.
Besides the production domains, additional domains ensure proper collaboration and task management across the dedicated production domains:
Root / Common resources / Common | Optional. If you use a Common sub-domain of Common resources, this domain also belongs to the production layer. Stores functional assets that are accessible by users. For example categories and keywords. |
|---|---|
Root / Global share | Shared assets between production domains of all organizational units. For example communication assets, projects. |
Production domains in censhare Dedicated solutions
The production layer of censhare Dedicated solutions comprises the following domains:
Media - the domain for media assets. For a Digital Asset Management solution (DAM), only this domain is required.
Content - the domain for all product-related content, such as text blocks and articles. For Enterprise Content Management solutions (CMS), this domain must be added.
Product - the domain for product assets. For Product Information Management solutions (PIM), this domain must be added.
The above domains are grouped below an Organization domain. This domain serves as a node. It allows you to set up multiple business units within your organization in parallel. The Organization domain itself stores no assets.
Online channel solutions (OC)
If you connect your DAM/PIM/CMS platform to an Online channel that serves one or multiple web portals, additional domains must be added to the domain tree:
System (OC) - contains the core functionality of the Online Channel (System layer).
Online - contains the customizations of the Online Channel (Solution layer).
Satellites - contains the web portals of your Online Channel.
Multiple organization branches
To represent an organizational structure with multiple units (for example, business units), create multiple domain branches:
Generic domain framework with two organization branches. The online solutions domains are not shown in this graphic.
Likewise, the censhare Dedicated solutions framework can easily be replicated to multiple organization branches:
Domain framework with two organization branches built with censhare Dedicated solutions. The online solutions domains are not shown in this graphic.
User configuration
Users work in their default role in their default domain. However, users also need access to domains that contain common resources and shared assets. When you configure new users, take into account the following requirements:
Role | Default domain | Additional domains |
|---|---|---|
System administrator | Root | - |
Solution administrator | Solution administration | Common resources (all permissions) |
Specialist | The working domain of the user | Common resources or common (write permissions), |
Consumer | The working domain of the user | Common resources or common (read permissions), |
To configure a user, add the respective default role and default domain. The default role gives the user the necessary permissions For example: create and edit assets, assign assets, create tasks, add comments.
Then, add the additional domains and select a role that gives the user the necessary permissions in that domain. The permissions in brackets give you a rough idea which permissions the user needs in the additional domains. The censhare permission sets allow a more fine-grained permission model.
If the censhare standard user roles (and their respective permissions) do not meet your requirements, create additional roles that you can use as additional roles in the user configuration.
Result
You know how to apply the new censhare standard governance model.