Quick Guide Dalet Flex: Assigning Roles and Permissions

Managing Roles and Permissions

Dalet Flex uses a combination of methods to manage user permissions. This guide explains these methods and how to combine them to control the objects you can access and the actions that you can perform on these objects. Some of the settings are configured in Flex Core and some are available from FlexMAM.

• Roles – control what users/members of a group can see and do in Dalet Flex
• Groups – allow you to control the visibility of objects in Dalet Flex for a set of users
• Workspaces –group a set of users that share specific assets that they work on collaboratively
• ACL (Access-control lists) - enable sharing objects with selected users regardless of the workspace they belong to

Managing Permissions Using Roles

Creating roles allows you to control what users can see and do in Dalet Flex. You can create roles based on the jobs that exist within your organization. For example, if you have a group of Editors in your organization, you can create a role that has permissions specific to that position. Roles can be assigned to an account or to a sub-account.

A role is a set of permissions for creating/viewing/using enabling etc objects in Dalet Flex. There are different types of objects in Dalet Flex:

• Configuration objects – for example, Workflow Definitions and Actions
• Operational objects - for example, Workflows and Jobs
• Asset objects – for example, Media Assets and Image Assets

The first stage of managing permissions in Dalet Flex is to create Roles.
Every user MUST have a single role assigned to them, but if a user is also part of a group/s and the group/s has a different role assigned to it, the user inherits permissions from both the user role and the group/s role.

See Roles and Permissions to learn about creating a role in Dalet Flex and assigning permissions to work with different objects.

Using Groups to Set the Visibility of Objects

Groups are used to manage a set of users. A group can be assigned to a role and any user in the group inherits the permissions for the role. A user can be a member of multiple groups allowing them to inherit permissions from multiple roles.

When you create objects in Dalet Flex, such as Actions, Workflows, Metadata Schema, Event Handlers etc, you configure the visibility of the object. The visibility of an object indicates whether it is available to a user or not. For example, if you do not have visibility for a Launch action, you will not see this action in the More Actions menu in FlexMAM or if a user runs a workflow via a wizard (i.e. is the owner of the workflow), and the workflow encounters an action that they do not have visibility for, the workflow will get stuck.

To increases granular control over the visibility of objects, you can set visibility for objects in Dalet Flex to a particular group/s in an account/sub-account.
For example, in Flex Core, in the New drop down list, select Action.

Give the action a name, and in the Visibility field, select an Account, Sub Account or Group that will have visibility on the action.

Using Workspaces to Manage Access to Objects

A workspace is a method used to silo assets, granting and denying users/groups access to specific assets. Users and groups can be assigned as members of the workspace to work collaboratively on assets. Every asset belongs to a single workspace and only users/groups who are members of that workspace can see the assets in the workspace. An asset is assigned to a workspace when it is created whether it is created by an Import Job or created manually in the UI as a placeholder.

Any workflow or job that is run belongs to the workspace that the workflow/job was launched from. This means that in Flex Core, you see a different set of workflows and jobs depending on which workspace you are in. When a new account is created, a default account workspace is created with the same name as the account. Any user that is created is automatically a member of the account workspace and has access to all workspace supported objects, such as assets, tasks, jobs and workflows created in this workspace (based on permissions).

You can create new workspaces and add users or groups as members of these workspaces. Once there are additional workspaces, these will be available in Flex Core and in FlexMAM as long as your Role has permissions on Workspaces. In Flex Core, the Workspace permission displays the Workspaces drop down list displaying the workspaces you are a member of. You can use the drop down list to switch between your workspaces.

The workspace marked with a green tick is the default workspace. This workspace is loaded whenever you login to Flex Core. You can change the default workspace by clicking on a tick beside a different workspace name.

In Flex MAM, if you have the Workspaces permissions, you can see all the workspaces you are a member of in the interface and switch between them.

A user can be a member of more than one workspace, but the user is always a member of the account workspace. By assigning different groups of users to different workspaces, you provide a means of grouping users to work collectively on assets.

There are different permissions for working with workspaces and these affect what you see in the search listings when you run a global search in both Flex Core and in FlexMAM.

See Workspaces to learn about creating workspaces, assigning users and groups to a workspace and understanding the way permissions affect your access to objects in Dalet Flex.

Managing Assets Access Permissions

By default, a user can only see assets that are in a workspace that the user is a member of. To extend the collaborative functionality in FlexMAM, you can give access to specific assets, regardless of their workspace using the Access tab in the Summary panel in FlexMAM.

You can select specific users or groups to share the asset with. Once the asset has been shared, the user is able to view and modify the asset even if they do not belong to the workspace that the asset is in.
See here to learn more about managing access permissions for specific assets.

Managing Permissions for Metadata Fields in Metadata Schema

By default, all fields assigned to a metadata schema can be viewed and edited by all Groups. You can limit access to metadata fields by specifying user groups that can view and edit fields added to a schema.

In Metadata Designer, select a field in a metadata schema and expand the Permissions section.

For each group, click the Access check box, to enable applying permissions on fields and select Read to give the group read only access and Write to give the group edit rights on the field. For example, you can give Read and Write permissions for a field so that the Editors Group have full permissions for the filed, whereas the Media group only has Read permissions.

Any Group that does not have any of the check boxes selected, has full permissions on the field.

If you select the Access check box but do not assign any other permissions, the field is not visible at all for users in the group. This is useful for fields containing sensitive sections of data.

Workflows check the metadata field permissions. If there is an action in a workflow to write metadata to a field and the user who started the workflow, (i.e. is the owner of the workflow), is in a group that does not have write permissions for the field, the workflow will fail.

Tips for Giving Permissions for Objects

The list of objects in the Permissions tab is extensive. Many of the objects and modules give access to parts of Flex Core and are not required by users that only work with Flex MAM.

Use this list of tips to understand how to assign permissions in a Role:

• Removing List permissions, removes an option from the Settings and Access menus. For example, if you remove List permissions for Users or Actions, these options will no longer be available in the Settings/Access menus. It does not remove them from the New drop down list.
• If you do not have list permissions in Flex Core UI, you will still be able to view objects in API using /api/objecttypename/objectid.
• Removing Create permissions, removes the object type from the New drop down list and removes the icon from the object type list.
• You can only assign permissions to a Role, if you have those permissions yourself. In other words if your role does not have list permissions for a particular object, you will not be able to assign these permissions to other Roles. They must be assigned by someone who has these permissions.
• To use Edit, Rename, Enable, Disable, Start, Stop and Delete, you must have View rights. If you do not have View permissions, you cannot view the Details tab of the object and More Actions and Bulk Actions are not available.
• To use Rename permissions, you must have Edit permissions. If you do not have Rename permissions, you can edit properties of an object but you cannot rename it.
• If a Role has visibility on Master Account, it cannot be edited on any other account because it is not visible on any other account.
• If a Role does not have visibility on any other account or sub-accounts, it can only be assigned in the account it was created in.
• To be able to access Flex Core, you must have at least these permissions:
  Apps > Flex Core
  Master Account > reference
  Users > View
  Permissions for at least one of the sections in Flex Core in the User Interface
  If you do not give permissions for Desktop Section, this error will be displayed, but you will be able to access the module that you have permissions for.

• To access Tags, Thesaurus and Taxonomy in Metadata Designer, a user must have at least Accounts > Edit permission and Act As permission.
• The Workspaces permission displays the Workspaces drop down list in Flex Core. If you have Switch Account & Workspace without Workspaces permissions, the Workspaces drop down list used to switch between workspaces is not displayed in Flex Core. You can view objects in different workspaces on your account by double clicking on any objects in the search results listing.
• Currently the Manage acl permission is not required for collections in FlexMAM, the owner of a collection can always share the collection.
• If you do not give permissions for any of the elements in a particular section in the User Interface, that section will not be displayed at all in Flex Core. For example, if you do not give permissions to both Failed Jobs and Search in the Jobs section, the Jobs tab will not be displayed in Flex Core.
• To give users read only rights to the Operational dashboard a user must have these permissions: Function - Act As, Accounts - View, Jobs - List, Workflows - List. Note, with these permissions a user will be not be able to cancel/retry workflows and will not see the workflow graph.