For many of us, working with Security Roles has become second nature. We create them, edit them, and manage them as part of our daily routine. However, for those who are just starting out, understanding the intricacies of Privileges and how to assign them can be quite challenging. This guide aims to demystify the process and provide clear, actionable steps to help you navigate the world of Security Roles with confidence. Whether you’re a seasoned professional looking to refresh your knowledge or a newcomer eager to learn, this article will serve as your go-to resource. Let’s dive in!
Key components of Security Roles
When assigning security privileges, there are two main components to consider:
- Privileges: These determine what actions a user with a specific security role can perform. For example, privileges can include creating, reading, updating, or deleting records.
- Access Levels: These define the scope at which the assigned privileges can be exercised. Access levels can range from user-level access, which restricts actions to the user’s own records, to organization-level access, which allows actions across the entire organization.
Understanding these two components is crucial for effectively managing security roles and ensuring that users have the appropriate permissions to perform their tasks without compromising the system’s security. In the following sections, we’ll explore how the differences between them and I would say we start with the second Item, the Access Levels.
Access Levels
As the name suggests, access levels define the scope in which a user can exercise their tasks. There are five different levels of access. For easier understanding, here they are listed with a short description:
| Access Level | Description |
|---|---|
| None | No access to the data |
| User | Allows actions only on records owned by the user. |
| Business Unit | Permits actions on records within the user’s business unit. |
| Parent: Child Business Units | Extends actions to records within the user’s business unit and its child units. |
| Organization | Grants access to all records within the organization. |
As we see, there are multiple options when assigning any privilege. Before we delve deeper into the Access Levels and start examples using Privileges, let’s list those privileges with some descriptions:
Privileges
| Privilege | Description |
|---|---|
| Create | Allows the user to create new records. |
| Read | Permits the user to view records. |
| Write | Enables the user to make changes to existing records. |
| Delete | Allows the user to remove records. |
| Append | Permits the user to associate the current record with another record. |
| Append To | Allows the user to associate another record with the current record. |
| Assign | Enables the user to assign a record to another user. |
| Share | Allows the user to share a record with another user or team. |
Special Considerations for Access Levels
Not all tables support all access types. For example, the Business Process Flows Base Table only supports None or Organization access levels. In conclusion, tables or entities created as Organization Tables and not User/Team Ownership only support Organization and None access levels.
only supports None or Organization access levels. In conclusion, tables or entities created as Organization Tables and not User/Team Ownership only support Organization and None access levels.
Privileges and Access Levels: Examples
Let’s explore each privilege along with the possible access levels and examples:
Create
Possible Access Levels: User, Business Unit, Parent: Child Business Units, Organization
Example: A user with the “Create” privilege at the Business Unit level can create new records within their business unit but not in other units.
Read
Possible Access Levels: User, Business Unit, Parent: Child Business Units, Organization
Example: A user with the “Read” privilege at the Organization level can view all records across the entire organization.
Write
Possible Access Levels: User, Business Unit, Parent: Child Business Units, Organization
Example: A user with the “Write” privilege at the User level can only update records they own.
Delete
Possible Access Levels: User, Business Unit, Parent: Child Business Units, Organization
Example: A user with the “Delete” privilege at the Parent: Child Business Units level can delete records within their business unit and its child units.
Append
Possible Access Levels: User, Business Unit, Parent: Child Business Units, Organization
Example: A user with the “Append” privilege at the Business Unit level can associate records within their business unit.
Append To
Possible Access Levels: User, Business Unit, Parent: Child Business Units, Organization
Example: A user with the “Append To” privilege at the Organization level can associate any record within the organization to the current record.
Assign
Possible Access Levels: User, Business Unit, Parent: Child Business Units, Organization
Example: A user with the “Assign” privilege at the User level can assign their own records to other users.
Share
Possible Access Levels: User, Business Unit, Parent: Child Business Units, Organization
Example: A user with the “Share” privilege at the Organization level can share any record within the organization with other users or teams.
Conclusion
Understanding and managing Security Roles is essential for maintaining a secure and efficient system. By grasping the key components—Privileges and Access Levels—you can ensure users have the appropriate permissions to perform their tasks. Remember, not all tables support all access types, so it’s crucial to know the specific requirements of each table. With this knowledge, you can confidently assign roles and privileges, enhancing both security and productivity within your organization.