Understanding Parent and Child Permissions

Introduction

The Roles that you create are made up from a range of permissions that allow the assigned user to complete certain tasks within CloudM Automate.

However, not all permissions are created equal. There is a hierarchy that means that some permissions simply will not work properly unless another permission has also been set. We call this a Parent and Child relationship - The Parent permission always needs to be set in order for the Child permission to have any effect. It is a prerequisite.

Example

A good example of the Parent / Child relationship can be seen when setting permissions to edit profile fields on User Profiles.

Let's give the admin the ability to change a user's job title. Looking at the list of permissions, it might seem obvious that you need to select the Edit Job Title permission (and you definitely should). However, this isn't enough on it's own. You also need to allow the admin to Edit Profiles in general (otherwise the admin simply will not have the Edit button available on a user profile)..

So, in this example:

• Edit Job Title is the Child permission (and won't work on it's own)
• Edit Profiles is the Parent permission (and is required if you want the admin to be able to edit the job title or any other user profile field that you add to the role).

Parent / Child relationship table

The table below shows the default CloudM Automate permissions that are displayed for all domains.

It does not include permissions that are displayed when a feature is enabled (e.g. Archive or Partner specific features).

A permission listed in the Child permission (level 2) column requires both the related permissions listed in the Parent permission and Child permission (level 1) columns to be assigned.