User Roles: Setting Up Your CORE For Your Users and Best Practices

User Roles are the way you grant user permissions in CORE. They are highly customizable to meet various security and team workflow needs.

To minimize the "lift" when setting up your system, we've listed some best practices and recommendations for creating your user roles and permissions that we've seen work well across different client environments.

In this article:

• Permissions: User Roles vs Package Sharing
• Before You Start: System Set Up Requirements
• Establish a Base Set of User Roles
• Define Your User Roles That Never Change
• Define Template Roles For New Projects and Productions
• How User Roles Work in Combination With Tags to Create Permissions
• Creating Access Controls That Enable Cross-Group Access
• User Overrides For Those Special Flowers
• Create Your User Roles

CORE Permissions: Understanding User Roles vs Package Share Permissions vs the New Folder and Tag Permissions

First, you must understand how CORE is setup to understand our unique permissions capabilities.  CORE is a two-part closed system with (1.) a DAM space called File Search where files are uploaded into the system to be stored, and (2.) an Inbox where collections of files are sent to system users for reviews, decision making, and collaboration. Think of File Search like your computer file directory or cloud-based Google Drive, Box, or Dropbox, and the inbox operates like your email.

User Role Permissions

When setting user role permissions, you're defining what a user has access to across the system (both feature-wise and files-wise) and how they can interact with the system itself (uploading, sharing, etc.).

User Roles Define:

• If a user can upload files and to where they can upload 
• If a user can share files in packages and how they can share
• How a user logs in and what parts of the system they see
• Whether or not they can download files from the system
• How secure the watermark is across different file types
• If they have additional admin controls to support their teams
• What projects or productions or groups of files they (users) can view and edit in the system
• Who they can see and share with

Package Sharing Permissions

There's an additional layer of permissions that every user has control over: the permission settings on the individual packages that they share. What permissions they can grant, however, are dictated by their user roles.

Package Permissions Define:

• Whether or not a package is view only, downloadable with watermarks, or downloadable from source. NOTE: CORE does not watermark source files. Downloaded watermarked files are proxies of the source.
• How a recipient can view the files online.
• Package restrictions
  • When and how many times a package and its file can be viewed
  • Whether or not users can see one another.
  • Whether or not users can comment on the files.

Folder and Tag Access Permissions

This is a new feature coming out with our next major build, CORE 7.0. The current build is CORE 6.6. 

As this feature evolves, Admins will be able to define user access controls on files and folders like you would in any other drive tool - on the files and folders themselves.

In addition to basic user role set up, and instead of file view and edit access rules locked into one role, you can now select a folder or tag in File Search, right click on it, and add a user or role to it in any combination. This permission becomes an add-on to any user role and an additive rule override to any user granted permission.

Folder / Tag Permissions enable:

• Easily adding access to tags and folders through File Search to an existing user role
• Easily enabling users with variable permissions to access those productions and files without having to create special user roles

Permissions Ranking: What Permission Types Overrides What

User Roles grant access to files and what users can be seen in the system, as well as define package sharing controls, upload/download capabilities, and a user's onscreen watermarks.

Package permissions can override the download permissions granted in a user role.

• A view-only user can be granted download permissions on a package when needed.

• Users with download permissions can be restricted to view only on a package when the sender thinks the materials are too sensitive to be downloaded.

Production watermarks override a user role watermark. 

• A sensitive project can be given a more secure watermark across all its files. Every user with access to that project, no matter their permissions will see that watermark.
• A stock library with archival footage that is non-sensitive may have no watermarks for easy perusal and selection.  All users with access to the library will see no watermarks, in spite of the watermarks applied to their role.

Before You Start: System Set Up Requirements

Before you can start defining user roles, you need to do one to three things:

1. Define your system's tag schema / taxonomy, including the values you and your users can choose from. Learn how to add your tag schema.
   • Tags (and soon folders) define what files a user can access in CORE, and they act as an access control.
   • A tag schema is the set of tag fields your users can choose from when they upload files into the system.
   • Those tags will be associated with the files.
   • The tags will appear as the "file path" in File Search and in the Browse panel of File Search.
   • They are also what you can use to find and search for your files.
2. Add your companies - Learn how to add your users' companies.
3. Add your departments - Learn how to add your users' departments.
   • If your user access rules (the rule that defines who users can see and share with in CORE) are dependent on either a user's company or department, then you'll want to add these prior to creating your roles. 
   • If your user access rules are tied to a production or project and the department of that production, then you can forgo these two steps.
   • Departments listed under productions or projects in File Search are not associated with a user's Department. In this case, Department is associated with the file data which is separate from the user Department data.

Establishing a Base Set of User Roles

When you first set up CORE, you need to define your base set of user roles. These are typically a combination of roles that --

1. will always remain the same and you'll keep adding users to them, such as an Inbox-Only Reviewer who only has permission to see what they are sent; and;
2. will be used as a template, so that they can be replicated for each new project.

You'll also have a unique set of roles for certain users or user groups who need a special combination of permissions.  Sometimes, applying overrides is the best practice, it just depends on how you want your teams to manage these users over time.

Define Your User Roles That Never Change

There are two base role types in the CORE system:

1. Admin - This is a system admin. In CORE, the Admin can do everything.
2. Standard - This is a user with no permissions whatsoever. They have an inbox. They can see what you send them and nothing else.

Everything else in between can be created through a combination of access controls.

For many companies, they have a set of three to five user roles that are applied to their studio or company departments. Those may include:

1. Inbox Reviewer - The user cannot upload nor download, cannot share other than to comment on and respond to packages that have been sent to them. These are typically your executives, creative directors, and the likes. 
2. Limited Inbox User - This user can respond to packages sent to them. They can also share files that exist in the system and re-share packages. They usually have access to a specific user company or user department. Often these are executive assistants, PAs, and coordinators who may be redistributing feedback from their boss, or managing the distribution of packages from within and outside of their working group.  
3. Inbox Uploader - This user has the above permissions, but can also upload. The only files they have access to in File Search are those they uploaded. Typically they can upload to a specific Domain or are restricted to Skip and Share packages which bypass tagging. These users are often vendors who are providing deliverables back to a team or project. 
4. Uploader User - This user has the above permissions, They can see, edit, and download the files of a specific department. These are your team users who are uploading and editing files in the system, and sharing with each other as well as other teams as a part of their daily workflows. 
5. Departmental Admin - This user can add users if working outside an SSO, potentially create roles in that case as well. They might be able to see other projects with approved assets and share those with the team. This is your team CORE owner, usually an asset manager or team supervisor or coordinator. 
6. System Admin - Users who are adding new productions to the system and configuring them for usability across devices. Typically your IT department, whomever is managing SSO, and your CORE product owner team, along with anyone else providing internal CORE support. 

Whatever base roles you land on, if departments are restricted to viewing their department only, you'll need to create a set of roles for each department where the user access group and file edit access changes. In this case, follow the template instructions to quickly create and replicate your CORE roles.

For specific documentation about how to set up your roles, go to User Roles: How to Create User Roles.

Define Your Template Roles For New Projects and Productions

For every new production or project you create where staff is contracted or dedicated just for that endeavor, you'll want to create a templatized set of roles that can be re-used across each project. Like your roles above these will typically be departmentally based.

Defining your templates:

• Create the base set of roles you'll need for each project. Examples:
  • Template_Inbox Reviewer - Only one role needed per production or project
  • Template_Inbox Uploader - Used for vendors and team members who need to distribute files only, you may have a combination of roles per team depending on need.
  • Template_Team User - Same as the Uploader User above
  • Template_Team Admin - Same as the described Department Admin above
• Name the templates by Template_Project Role Name
• When you create the actual role from the template, rename the roles to batch them in your User Roles list by production or department, such as
  • Production Name_Department_Role Name 
  • Department_Production Name_Role Name

Once these template roles are created, follow the instructions in How to Create User Role Templates to replicate them and create new roles from them quickly and easily.

How User Roles Work in Combination With Tags to Create Permissions

User Roles leverage tags to create access controls on files. When granting additional access to files or users, you create a rule with conditions.

• View rules grant view-only access to files.
• Edit rules grant view and edit access to files, which includes editing the tags associated with a file and adding, moving, or removing a file from CORE. 
• User rules grant view and sharing access with the users defined in the rule.

Here are some example rules:

1. Example: View access rule enables users to see the files of a production that are approved.
   • 
2. Example: Edit access rule enables users to view and edit all files and metadata within a production
   • 
3. Example: View and Edit access rules combo enables users to see and edit the files of their business unit, plus view all project and production files with a Status of Approved
   • 
   • 

Creating Access Controls That Enable Cross-Group Access

Sometimes you have departments who need to have access to other production or projects, libraries, or even specific files from another department. If giving access to those files isn't best suited in a package share, then providing File Search level access is done through Access Rules in the User Role.

To create wider and yet specific access, you will create a combination of access rules. 

In such cases, you'll have some combination of the example rules below:

• Edit or View Access Rule for the team, department or business unit
• View Access Rule for all productions and projects including a status condition, such as Is Discoverable, Editorially Approved, or OK for External Use
• View Access Rule for a specific asset library, such as Stock Footage
• And so on

User Overrides For Those Special Flowers

When you have individual users who require a special combination of access, and it's more problematic to assign them to a role or create an entirely new role, you have the option to "override" a user role. In these cases,

1. assign a user a base role that best fits their functional needs
2. go to that user's profile and select the tab Rules Override
3. here you'll have access to all the user role controls
4. start adding or changing rules as needed with creating another role

User overrides are additive. Overrides are highlighted to show where your changes diverge from the original role.

In the image below, under Domain, the red outlined items are a part of the rule. The dark blue selection is an addition to the role settings.

Overrides for this user are highlighted in blue, showing the Admin what has changed.

When to Create a Unique User Role

Sometimes managing user overrides is more of a hassle than quickly replicating a user role and adapting it for a single or small sub-group of users.  Title it in a way that's easily distinguishable, so if others also need access to the same permissions, you have it handy later.

In the end, do what's going to create less work for you and be more manageable and scalable for the life of your system. 

Create Your User Roles

To learn how to create user roles, see the following articles:

• User Roles: An Overview of User Role Features
• User Roles: How to Create User Roles
  
• How to Create User Role Templates