Three Steps to Simplifying Slate Security

Paraphrasing a famous theoretical physicist: “Everything should be made as simple as possible, but no simpler.”

Slate has many layers and is, by necessity, complex. We ask it to do a lot for our operations, and it generally does it all exceptionally well. Concepts transfer. Learning to write a Configurable Joins query in one part of the system means it works in the same manner for the rest. 

But what about security and access? Because of Slate’s necessary complexity, there are a lot of options to parse through.

Every new feature brings the potential for new security configurations. As of early March 2024, there are 80 standard permissions in the system for user record permission setup. (This is if you don’t count the permissions located under the query and record options. There are far more if you have custom permissions setup in your system, and more yet if you look around other parts of the system.) 

Knowing this, your temptation might be to give out the Administrator (All Access) role to lots of users. 

Don’t.

Beyond numerous potential security issues, having a less experienced Slate user setup as an “Admin” creates an experience that is suboptimal from a usability standpoint. They will see fields and tabs that are irrelevant to the work they do or that may not be set up. They will see options that have ominous warnings (looking at you, “Force Execute”) that involve nuances relative to actual impact on the system. They will experience a complexity that is potentially wasteful of their time relative to how they navigate Slate. Allow Slate to compliment their work but not get in the way. Aim toward keeping the Slate user experience both eloquent and intuitive. How you set up permissions will drive this.

(Also consider in-line documentation via Slate Scholar Custom Content or customizing record dashboards–that is a different article, though.)

Here are some additional steps to simplifying your Slate security. 

Step one: Use roles for permissions whenever possible.

A role is a group of permissions for a user. Roles are often grouped by job (Admissions Coordinator, Gift Processing Assistant, Student Advisor) or function (Deliver Message Sender, Constituent Inbox Manager, Decision Releaser). Setting up a role requires some knowledge of how your organization works. Ask yourself: ‘Who does the “thing?’” 

Think through all of the permissions needed to give them the ability to do the “thing.” Beyond organizational awareness, you will need to read and understand the standard permission documentation to do this. That said, it will pay off greatly when you have to manage multiple groups of users and combine settings across many permissions.

The power of roles is that a single user can have multiple roles assigned to them. Roles can also be managed globally over updating individual users. When Technolutions adds the 81st standard permission, how it will be used or not may be evaluated from a role perspective as opposed to having to evaluate it for all of your individual users.

For example, you have an International Admission Coordinator who is student “facing” and mainly uses Slate as an information source, and also occasionally needs to send text reminders to a group of prospective students working through the F1 visa process. You could create a security role for the main job (that other users share) and a role for sending group messages out of Deliver constrained to this particular set of prospective students.

Step two: Consider using Application by Population (Query – Application permission) and Person by Population (Query – Person permission) as the basis of distributed queries, reports and Deliver communications.

Populations have traditionally been used in the world of graduate admissions to control access to records via the Reader, or more generally, for “drip” communication campaigns. A population in Slate is simply a grouping of person, application or dataset records by some criteria. For example: “all accepted international students who applied in 2024”. Like roles to users, a single record can belong to multiple populations.

For the example above, you could create a “rolling” population set by the active status of the period or round the individual is applying through, a released decision and other criteria. This will ensure that the population is always current but does not require anyone to adjust the population rule (other than following the standard updates done through cycle “prep” on an annual basis). You can then set access to this query population using the Populations tab on the user account.

Keep in mind within the user setup, the permissions set on the Permissions tab, either individually or via a role, override ones set on the Populations tab. Permissions set here are “global” vs. population based. Having Query (edit all users) set for a user on the Permissions tab will override population-based security from a query standpoint and the user will be able to query against all records. 

The by Population query base approach gives you: 

• • Security: The user can only query records they should have access to in their normal course of work.
  • Risk mitigation: Users that are less experienced with queries and the Deliver tool can only send messages to the group defined and no one else. This can be managed independent of Reader/Record access by controlling Query – Application on the population setup.
  • Simplicity: You would not need to train every end user to work through the various logic points in all of the queries they might write–the population does it for them.
  • Ease of distribution: You can have a single, standard report or query that works for all the end-users based on their population security–gone are the days that you need to copy the query dozens of times and maintain each indefinitely–the query/report can also be setup so the end user can run it but not modify it. Realms for queries are fine but not necessary if you use this approach. 

A word of caution: Population rules always run on a record as it is evaluated for inclusion as part of deferred rules processing. Because of this, make sure that queries setting populations are efficiently written and use exclusivity groups when possible. Having many inefficient population-based rules can slow the system down.

Step three: User Impersonation

If you are reading this article, it is highly likely that you have Security Administrator exclusive permission associated with your account in Slate. It is very easy to fall into a mindset that your experience as an “admin” is similar to what most users of Slate have and see. Also, how different permissions interact can be complex in Slate. Your best tool to see an accurate picture for your users is user impersonation. 

With it, you can interact with most records and forms as though you were the user and see what they can and can’t do. Have a couple of test records ready to experiment with for this purpose.

This is of paramount importance when setting up the by population based queries, as you only see the query results as displayed for end users via impersonation.

Good luck and keep it simple (but no simpler than it needs to be).