Access to assets in the Marmind integration

Comparison of the governance (access rights) models in Marmind and Censhare and which is applied on which stages.

Introduction

A governance model is a set of rules that defines:

which assets you can see
what you can do with them

Governance models in Censhare and Marmind have a few things in common, but also a few differences.

Most importantly, those two governance models:

are not synchronized
are applied to different user actions in the UI

This sections helps you to understand how this influences your work.

Censhare governance model

Detailed information can be found in the following articles:

Below you will find a short summary of it.

Information for Censhare newbies: Censhare governance model

In a nutshell, your access to assets in Censhare is governed by:

domains
roles

Domains define which assets you can access, whereas roles define which access you have to those assets, i.e., what you can do with them.

Domain concept in Censhare

Domains are one of the most important concepts in Censhare‘s data and governance model.

Domains represent an abstract hierarchy, with the root. node being on top of it. Nodes below it have more narrow “scope” than the root. node. See the diagram:

`root.`
`root.dach.`		`root.fr.`
`root.dach.sales.`	`root.dach.legal.`	`root.fr.sales.`	`root.fr.legal.`

Domain names are built using dots. The first part of the name (on the very left) is always the root.. When you move to the right, you go down in the domain hierarchy. I.e., root.dach. and root.fr. are both parts of root.; it means that they are “smaller” than root., and that everything that belongs to one of them is separated from everything that belongs to the other.

It is possible to have a second such hierarchy. It would also start with the root. node, but have different nodes below it.

Therefore, domains help to implement organizational structures in the DAM system, e.g., geographical units and/or brand units.

Any asset in Censhare has to be assigned at least two domains: the 1st domain representing the asset‘s place in the main hierarchy and the 2nd domain (which is optional and can be just root.).

Since users are also assets, they are also assigned with two domains.

When an asset and a user are assigned the same domain(s), the user has access to this asset.

Roles

Which actions a user can perform on the assets, is defined by their role(s). A role is constructred in a hierarchical way as well, but those hierachies are more flexible.

In Censhare, the “smallest” unit of permissions are called keys. Censhare system offers more than 100 keys, each representing a very narrow action, such as editing, deleting, creating, etc. Often, the allowed action is also tied to a certain asset type.

It is not possible to assign permission keys to users directly. Instead, an admin needs to bundle them: first into permission sets and then into roles, e.g., one permission set includes multiple permission keys, and each role includes multuple permission sets.

How roles and domains work together

Roles and domains are assigned to users in triplets. One such combination includes a role, a 1st domain, and a 2nd domain. One user can be assigned multiple such combinations.

E.g., a user can be granted a read access to assets on the domain root.dach. and a write access to assets on the domain root.fr..

Marmind governance model

The official third-party documentation on this topic can be found here.

Objects

As already mentioned, the core concept of Marmind is an object, and everything around campaign management is organized hierarchically, with objects representing levels of that hierarchy. The access to objects is also governed in a hierarchical way.

In a nutshell, having access to the higher level gives you access to everything below it in the hierarchy. This is similar to the Censhare domain concept: access to a domain means access to all its subdomains.

`organization`
`workspace`		`workspace`
`campaign`	`campaign`	`campaign`	`campaign`

The difference is that objects in Marmind are also tightly connected to the corrsponding UI elements in the web client, and the object tree is always present in the UI.

In Censhare, access to domains may affect which UI elements the user sees in the web client, but this relationship is not straightforward.

Roles and rights

Similarly to the Censhare system, rights are single permission keys and roles and their bundles. Together they define which kind of actions a user can perform.

Teams

Teams are groups of users and user groups. They can be assigned to an object on any level of the hierarchy to make it visible for the team member. However, there is no top-down affect in this case: the teams only sees one particular object and nothing above or below it in the hierarchy.

When each model is used

When you are logged in to Censhare, it is governed by Censhare which assets you can access. When you logged in to the Marmind UI, this is two-fold. In general, you have a separate user in Marmind which is not synched with your Censhare user. It means, when you are moving around in the Marmind UI, what you see is defined by the permissions assigned to your Marmind user.

However, at particular stages, the access is again governed by Censhare:

when you are browsing Censhare assets while staying in the Marmind UI for the purpose of adding them to Marmind objects
during the file upload, regardless of which UI you are using
during duplicate check that follows a file upload in Marmind

These rules have important implications, For instance, when you upload an asset to Censhare/Marmind, it is assigned to the domain of your user. Make sure your collaborators can use it later.

Troubleshooting missing access

If you expect to see certain assets and/or actions (editing, deletion, etc.), but this is not the case, please check one of the following:

if you are in the correct context (object in the object tree)
if the asset has been assigned to a matching domain

Contact your admin to make sure your user has been given correct roles, rights, etc.