What access (or permissions) a Slate user has can be controlled by multiple variables within Slate, which are broadly categorized into:
User Access - What system tools or features can the user access? (e.g., the Reader, Deliver, etc.)
Record Access - Which records can the user access? (e.g., all records, only application records, only records added to a certain population, etc.)
Object Access - What database objects can the user access? (e.g., specific queries, deliver campaigns, forms, events, etc.)
By combining the tools provided across all three categories, very detailed and graunular limitations can be placed on an individual user and what they are able to do within the system. It can often seem that there is much overlap between the tools used to customize the specific permission/access a user has. For example, system permissions refer to access to tools (Deliver) as well as records (Application Lookup).
It can be helpful to think about what tool the user is accessing vs. what records they are accessing vs. what objects they are accessing. For example, the ability to look up application records is the system permission, and which records can be viewed is a record access question. So a user must be given the system permission to use the lookup tool to have the ability to look for records, but a record access permission (usually via population) can then be added to limit the specific records they can view. Similarly, to access the Query tool a user must have a system permission to Queries, but which queries they can open and view could be limited by an object permission (realms).
Depending on the complexity of the database, adding record access or object access permissions may or may not be necessary, but user access permissions are fundamental and required.
User Access
Slate has two primary “types” of user permissions – standard and exclusive.
...
Custom permissions are unique to each database/instance and are added/created by admins to control access to many different objects in Slate. They must be created, assigned to the object, and then assigned to a user/role in order to work.
Reader / Workflows
Disable Old Reader
From Technolutions Staff in Forum:
https://knowledge.technolutions.com/hc/en-us/community/posts/7705197665051-Turning-off-Old-Reader
You can disable the default Reader within your Applications query base by changing the below setting to "No":
...
Clicking the Reader will then only present the option to choose which workflow to enter if a user has permissions to see multiple. If a user can only view one workflow, it will take them directly into that workflow seamlessly. As you've already noted, it's best to try this out in your test environment to ensure everything works as intended before you do so in production.
I'll echo Josh's sentiments on workflow access as well; I would recommend double checking the read permission set for your workflow here:
...
Each new workflow will populate with this field set to Reader by default. If a workflow is intended to be accessible by select staff and not the entire body of readers, we would recommend updating this to a custom permission.
In both cases, this will come down to whether your staff have the appropriate read permission, so assigning them separate permissions that correspond to what they need to see within Reader should partition this nicely.
The Classic Reader will be referencing this read permission within the query base that your reader bins are built on:
...
The Workflow Editor looks to the Custom Reader Permission:
...
If possible, it would be smoother to migrate all staff from the Classic Reader to the Workflow Editor all at once and turn the Reader setting off within your query base, as this will ensure that it will no longer be visible for all of your staff.
...
Roles
Granting permissions through a role allows for the ease of adding or removing specific permissions for multiple users because they will update across any user who has been assigned that role. It is also a great way to consistently grant the same set of permissions for each user carrying out the same role.
Additionally, a user can have individual permissions layered on top of those that are inherited from a role. For example, a user may be granted a faculty reader role but is also the events coordinator, so they may be granted the individual permission of Events (edit all users).
Record Access
notes from Helen’s research into population permissions done in 4/2023 using KB and webinars.
A population in Slate is just a label for a group of records. Population rules are used to define and enroll records in the population.
The scope of the population will determine which kind of rule can add records to the population.
Population-capable or population-aware permissions are permissions that can be given to users that will be inherited for records in a selected population, as opposed to all records. They are included within the system permissions master list, but only a sub-set of system permissions are population-capable.
How to Grant/Use Population Permissions:
Use the populations tab on the user account
Permissions granted in the permissions tab will override the population restriction, so don't add the 10 population-aware permissions on the permissions tab
Can grant either individually by permission or through role
User will inherit any population capable permissions in the role for the selected role and the other non-population aware permissions (functional permissions) in that role will also be granted (don't need one role for functional and one for population-aware)
Can grant access to more than one population at a time
Once applied:
Users can only get access to records in a granted population, can use the universal search and may see names of non-population records but won't be able to go through all the way to the record.
In reader, will only see application records that belong to a certain population. Can still see bins, because that's controlled by permission settings on the bin, but won't see the records (will show 0)
In release decisions, will only be able to assign, confirm, and release decisions on records enrolled in a granted population.
Roles or permissions assigned from the "roles" tab are not population-aware.
...