Slate has two primary “types” of permissions – standard and exclusive.
Exclusive permissions are unique; they have security implications and are excluded from assignment through “inherit;” they must be added intentionally and should be reserved for admin users only.
System permissions are the “main” type of permission; they grant access to the majority of the records, tools, and functionality within Slate. These permissions are further broken into two categories:
Population-capable permissions - permissions that can be given to users that will be inherited for records in a selected population, as opposed to all records.
General permissions - permissions that can be given to users that will be inherited for all records, regardless of population.
KB Article overview of https://knowledge.technolutions.com/hc/en-us/articles/360050427751-System-Permissions#permission-descriptions-0-1
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.
However, if you need to only move Undergraduate for now, you can ensure their permissions are structured so all Undergraduate staff are set with the read permission for your workflow, then adjust your query base read permission to a separate custom permission that your Graduate staff have assigned. A quick test in my environment following this outline results in having my Undergraduate and Graduate staff accounts restricted to only access what they should be seeing within Reader, but I encourage you to verify this within your test environment to ensure it looks right for you and doesn't impact any other processes.
Add Comment