Access Control Overview

Albert is committed to sharing knowledge and enabling collaboration while protecting Intellectual Property (IP). To do this, access controls are put in place to ensure information is properly protected.

If you have questions about the level of access you have been provided with or would like to request access to certain objects in the platform, please reach out to your organization's Administrator. 

Albert Access Control Summary

Albert access controls are made up of two levels of access:

1. Access to perform certain operations (call certain APIs) 
2. The ability to perform operations on certain objects in the system (tasks, inventory items, etc.)

To limit actions users can perform, Albert has Roles, which allow users access to perform certain operations (point #1 above). This allows businesses to restrict create, view, or edit access to different objects if a user does not need to be able to perform these actions. To have access to certain objects (point #2 above), users need either 1) named access to that object or 2) to be part of a certain user class (where users will be granted access in bulk to many objects). Because different objects in the platform have different business objectives, they need different levels of access (i.e. Formulas vs. Inventory items).

The majority of users will be Standard users who can be granted named, explicit access to be able to edit certain objects within the system. 

Definitions

The terms mentioned above are further outlined below: 

• Roles are user types that are customized by each organization. Each Role represents a unique combination of access to certain Policies, which are a list of operations that a user can perform (APIs that a user can call). 
  • A Role allows you to answer the question, "Can I perform this operation (call this API)?" 
  • For example, a user that has Full Access to the Albert platform has access to every single Policy.
• User Classes are default classes that are applied to users in the Albert platform based on the designation they are given by Albert platform System Administrators at your organization.
• Object classes are default classes that are applied to objects in the Albert platform based on the object category they fall under. Click here for a full list of Default Object Classes.
  • The Object + User Class allows you to answer the question, "Can I perform this operation on this object?"

Providing three layers of access allows organizations to flexibly customize access based on their specific requirements.

Object and User Class Summary

All objects (Tasks, Inventory items, Projects, Lots, etc.) and Users are given classes in Albert, allowing for granular, customized management of access to every object in Albert. Combined, these classes reduce the overhead of managing access control on an object-by-object and user-by-user basis.

The image below summarizes the currently available User and Object classes in Albert, and the access Users will have to given object classes based on their user class.

• I - Implicit: Access is granted by default without requiring named access
• E - Explicit: Named, explicit access is required

User Classes

Each of the available user classes are outlined below:

Standard

Standard users have full access to all shared objects (read and write), but have to be granted named access to edit other objects.

Standard users can view all restricted objects details and lists, but need to be granted named access for edit rights

Example: 95%+ of the user base. All core users

Trusted

Trusted users are given default rights to all restricted objects. This means that trusted users can edit all property tasks, general tasks, parameter groups, and data templates (assuming their policy gives them this access).

Example: Program Teams, Centers of Excellence - edit all tasks, data templates, parameter groups, etc.

Privileged

Privileged users are by defaults able to view and edit all private objects, restricted objects, and shared objects. These users, by default will have rights to all formulations (assuming their policy gives them this access).

Example: Regulatory Teams - ability to manage all restricted (verified) inventory items or see formulations to manage in SAP

Admin

Admin users have access to everything a privileged users does, but they also have full access to confidential objects.

Example: System Admin

Object Classes

Each of the available object classes are outlined below:

Shared

Shared objects are objects that all internal users have read and write access to. Guest users will need to have explicitly named access to view or edit these objects. Inventory items are an example of a shared object in today’s setup.

Example: Inventory

Restricted

Restricted objects are objects that are viewable by everyone (except guest), but edit rights are limited. Tasks, Data Templates, and Parameter Groups are examples of objects where everyone can see the details, but only named individuals are able to edit the details.

Example: Tasks - only creator and owner are able to edit

Private

Private objects are objects that are visible in lists, but are not visible for the details. Formulas are an example. Everyone can see all projects in the search page, but only users with names access can edit the details.

Example: Projects - you can see the projects listed, but cannot see formulations

Confidential

Confidential objects are hidden in lists and details except to named access individuals. Confidential projects are an example where only users with access are able to even see these objects in the search lists.

Example: Projects - once confidential, you are not able to see them in search pages

 

 

Policies

Policy Name	Product Area	Description
Projects - View Access	Projects	Ability to view projects.
Projects - Edit Access	Projects	Ability to view and edit projects, but not able to create new projects.
Projects - Full Access	Projects	Ability to view, edit, create, and delete projects.
Formulas - View Access	Projects	Ability to view formulas.
Formulas - Full Access	Projects	Ability to view, edit and, create formulas.
Tasks - View Access	Tasks	Ability to view tasks.
Tasks - Full Access	Tasks	Ability to view, edit, create, and delete tasks.
Inventory - View Access	Inventory	Ability to view all Inventory.
Inventory - Full Access	Inventory	Ability to view, edit, create, and delete Inventory.
Parameter Groups - View Access	Parameter Groups	Ability to view all Parameter Groups.
Parameter Groups - Edit Access	Parameter Groups	Ability to view and edit Parameter Groups, but not able to create new Parameter Groups.
Parameter Groups - Full Access	Parameter Groups	Ability to view, edit, create, and delete Parameter Groups.
Data Templates - View Access	Data Templates	Ability to view all Data Templates.
Data Templates - Edit Access	Data Templates	Ability to view and edit Data Templates, but not able to create new Data Templates.
Data Templates - Full Access	Data Templates	Ability to view, edit, create, and delete Data Templates.
People - Edit Access	People	Ability to view and edit users, but not able to create new users.
People - Full Access	People	Ability to view, edit, create, and delete users.
Access Roles - Full Access		Ability to view, edit, and create roles and policies.
Reports - View Access	Reports	Ability to view all Reports.
Reports - Full Access	Reports	Ability to view, edit, create, and delete Reports.
Templates - View	Templates	Ability to view all templates.
Templates - Full Access	Templates	Ability to view, edit, create, and delete templates.
Lists - Full Access	Lists	Ability to view, edit, create, and delete lists.
Locations - Full Access	Locations	Ability to view, edit, create, and delete locations.
SDS - Full Access	SDS	Ability to view, create, and download SDS.

For a complete list of API endpoints associated with the above policies and roles, please visit here.

 

Access Control Examples

Full Project Access - Standard User

Zack is given Full Project Access and is a Standard user: Since they have full project access, this user can navigate to the Project module and create new projects. Because they are a standard user, they can edit ONLY projects they have been given access to.

 

Full Project Access - Privileged User

Liz is given Full Project Access and is a Privileged user: Since they have full project access, this user can navigate to the Project module and create new projects. Because they are a privileged user, they can edit ALL projects which are Shared, Restricted or Private. They CANNOT see or edit confidential projects.

 

View Project Access - Admin User

Thanh is given View Project Access and is a Admin user: Since they have view project access, this user can navigate to the Project module. They cannot create new projects because they only have view access. Because they are a admin user, they can view ALL projects which are Shared, Restricted or Private or Confidential. But they cannot edit any projects because they only have access to view the projects.