OverviewUser HierarchyDepartments / TitlesUsersCreating a Department / Title / UserWork HierarchyClients / Projects / TasksCreating a Client / Project / TaskWorking with ListsTime SheetsNon-working TimeHolidaysRevenue / RatesReportingReporting AccessRolesCreating a RoleSecurity LevelsReference FieldsCustomizing Your Instance
Security Levels
A security level, when applied to a role, is how the system grants access to certain tables and fields. Each security level record has a table, and a role associated with it. Within the security level there are two access sections, table access and field access. The two access levels determine what the user can do with the records associated to the table.
Creating a Security Level
- Click “Security Level” on the left navigation.
- Click the “New” button.
- Fill out the Table and Role.
- Click “Create.”
Once you create the security level the table and field access sections will appear. See the documentation on those sections for more details.
Table Access
This is the first check performed when accessing a record. If a user doesn't have table level access (through one of their roles) to a record, they will not be able to access it.
There are four possible actions on every table: create, read, update, and delete. To perform an action on a table, the user needs to have a role associated with that action.
Left Nav is also an option in the table access section. If this option is selected, then the table will appear in the left nav for users with the role.
There are some situations where not all options will appear for every table. Some tables don't allow creating new records. For example, the List View Config table only has read, update, and left nav. This is because creating and deleting these records is not allowed at a system level.
Field Access
Security levels can be set up to give a user access to the table but limit them to seeing only specific fields. For example, if you want someone to have access to the user table but not see start dates, you can create a role that gives them access to read the user table and only view the user's name.
A note about reference fields and field access. If a field is a reference to another record the user will also need read access to the reference table and the field being shown (i.e., the user's name). For example, the project manager on a project record is a reference to a user. For someone to see the project manager on a project they need access to read the user table and they need to be able to read the name field on the user table. Within the field access section reference fields are clearly marked.