Domain concept

Domains are the most elementary structural elements in the censhare governance model. Domains allow you to build your organizational structure in censhare. For example, you can keep your business units separated in your censhare system.

Context

The mandatory domains for the censhare core system and system configuration are part of the censhare standard product. As of censhare 2019.3, a new mandatory domain structure is introduced. The new domain structure allows the implementation of a consistent governance model for the censhare dedicated solutions and custom solutions.

Introduction

Technically, the domain tree in censhare is a hierarchical structure of nodes, starting from the top-level  root node. In censhare, there are two domain trees (called 1st domains and 2nd domains) that are completely independent from each other. The 1st domains tree is always required. It also contains the mandatory domains for the configuration and administration of your censhare solution.

The 2nd domains tree is optional and only necessary for more complex governance models. For example, if you want to manage several business units and several brands in your censhare system, instead of building a redundant domain tree with a dedicated domain for each business unit/brand combination, it is more convenient to built a 1st domains tree that contains the business units, and a  2nd domains tree that contains the brands. You can then assign each asset to a business unit (1st domain) and a brand (2nd domain).

The domain tree is built up of nodes and paths. A domain is represented by a single node. All nodes have their origin in the root node. Before running censhare in a production environment, the domain trees must be defined, implemented and tested.

Example of a custom domain tree (only 1st domains):

Assets and master data (for example: features, relations, users, workflows) are stored in domains. Assets are always stored with a 1st and 2nd domain. Each item has exactly one 1st domain and one 2nd domain attribute.

Assets are usually stored in the domains in which the user that creates them is logged in. The domains of an asset can be changed by any user (limited to the domains that user has access to), or automatically (for example, if an asset is put into another workflow step).

It is not possible to store an asset without a 1st and 2nd domain. If an asset cannot be assigned to one particular domain, it will automatically be stored in the root domains. This can be the case when you import assets into your system and the domains stored in these assets do not match an existing domain.

Domains of master data are defined in the system configuration and can only be changed by a system administrator.

Benefits

The censhare domain model has three main purposes:

1. Assign domain nodes to the file system for the storage of asset files: censhare can be set up with multiple file systems. Each file system must be assigned to one domain. If an asset is in a domain node that has no file system assigned directly, the asset is stored in the file system that is assigned to a parent node of the current domain. As a rule of thumb, one file system should always be assigned to the root node of the 1st domain tree. It is possible to assign a censhare file system to one node in the 1st and 2nd domain trees, but the up-the-path-decision of the system, where to store the file, becomes quite confusing when doing so. It is therefore recommended to do all file-system assignments only in one of the two domain trees.

2. Manage the role and permission model for user accounts:  Users can only see assets that belong to one of the domain nodes that a user has access to, and child domains of these domains. Assets in sibling and parent domains cannot be accessed, viewed, or found in a search. The domain restrictions are checked on the server on each client request, which provides robust and reliable multi-client capabilities. The domain restrictions are also applied to the master data editor of the censhare Admin Client. This allows to create Sub-Administrators that can change master data only within their domains.

3. Use domains as search criteria:  This qualifies the domain trees as an organizational tool, that can represent your organizational units, business segments, geographical distribution of subsidiaries, etc. When users with access to multiple domains and domain paths search for assets, they can use domains to filter the search results. However, this requires a domain structure that is comprehensible and intuitive for users, which is not always possible, since other criteria can prevail when setting up the domain trees.

Data model

In the censhare data model, the 1st and 2nd domain trees are stored in the Master data/1st Domains and Master data/2nd Domains tables. A domain node is represented with dotted path notation (for example:  root.solution-admin.organization.content.). Each node path must be unique. Domain nodes are stored in asset references, or all other related data in their full path notation.

First domains

The  1st domains tree comprises the mandatory domains of the censhare standard product, and the organizational layer that can be freely created/customized.

The mandatory domains of the 1st domains tree are the root domain, the common resources nodes, and the global share  domain. These domains are required to implement a consistent governance model that separates the administration of the censhare core system from the configuration and administration of your solution.

Below this mandatory domain structure, you can either use the domain framework for dedicated solutions, or create a custom domain framework that represents your organizational structure.

The following table shows the associated governance model for the 1st domains:

Table info

(1)  The GREEN domains are part of the censhare standard product. These domains are mandatory. They ensure the implementation of a consistent governance model. Ensure that all users have at least read access to these domains.

(2)  The BLUE domains are optional and only necessary if you connect an Online channel to your censhare system.

(3)  The GREY domains represent the censhare organizational layer. Production assets are stored in the domains of this layer. You can add any number of sub-domains and depth to the organizational layer, or use the domain framework for dedicated solutions.

Use GLOBAL SHARE domain as your communication domain

By default, censhare stores communication assets (messages, tasks, markers, and topics) in the same domain as the parent asset. For example, a 3D model belongs to the Media domain. Media specialists work in this domain. Their comments on the 3D model asset are also stored in the Media domain.

When the 3D model asset is moved to another domain (for example: to the Product domain), the users in that domain (for example a Product specialist), may not see and cannot reply to the comment, because the comment is not stored in their default domain.

As a best practice, we recommend to define the Global share domain as communication domain for dedicated solutions. The communication domain is configured in the System asset. For more information, see the section Alternate domain for new child assets in the communication tab  in the System asset.

Second domains

The  2nd domains tree is reserved for specific purposes. For example, you can use it to represent brands, regions, countries, subsidiaries, or others. If none of these is required for your business case, you can set up your system without the 2nd domains tree. In this case, all assets and master data are automatically stored in the root domain of the 2nd domains tree.

Planning the domain tree

One of the most important initial tasks during the implementation of a censhare system is to model the domain trees. A well-designed domain hierarchy is a key factor for the effective roll-out of censhare in your organization.

Usually, the domain tree is designed by censhare professionals together with the customer. The censhare dedicated solutions provide a pre-defined domain tree (only 1st domains) that can be used as is for many solutions, or adjusted easily to more complex solutions. Contact our professional services to find out whether a fully customized domain tree, an out-of-the-box dedicated solutions domain tree, or an adjusted dedicated solutions domain tree is suitable for you.

Best practices for a custom domain tree or a customized dedicated solutions tree

• Start with the 1st domain tree. Only use the 2nd domain tree if there is good reason to do so. As a rule of thumb, the 2nd domains tree is necessary if redundant nodes/paths exist in the 1st domains tree. For example, in multi-language environments, the 2nd domain tree can be used to represent different languages.

• Make file system assignments only within one domain tree. Distributing file system assignments to both trees makes it difficult to determine, which file system is used for a given asset.

• Plan for the future. Your company might have only one office at one place, and there might be only one centralized filesystem. Prepare the domain trees to expand: add additional offices, additional file systems that are represented by nodes in the domain tree. Include an extra level that represents the different subsidiaries in the domain tree hierarchy, even if it contains only one node in your current setup.

• Give each level in the domain tree hierarchy a dedicated purpose. For example: one level represents offices. One level represents business segments, and another level 3 represents publications.

• Make a clear decision, which structural elements/units in your organization are represented in the domain trees, and which are represented by other organizational features of the censhare system, such as keywords, asset categories, groups etc. As a rule of thumb, the domain tree should be kept as simple as possible and only include nodes that are needed for your governance model and/or file system assignments. For example, different publication channels can be represented by domains, but issues/publications within one channel should not be stored in different domains. Products can be stored in the same domain, unless you manage different brands or product lines, that can be stored in their own domains each.

• If you use the translation application of censhare, it is usually necessary to create dedicated domain nodes for the different languages.

Result

You are familiar with the censhare governance model of mandatory domains, and the domain concept of 1st and 2nd domain trees.