User accounts, and the permissions bestowed on them, determine who can access your Slate database and what they can do in it.

Access user accounts in Database → Users & Permissions.

Users

To grant someone access to your Slate database, create a user account for them. Slate supports unlimited user accounts.

Security administrators create new user accounts

The only users who can create new user accounts are those with the Security Administrator permission.

Security administrators can create user accounts for a variety of user types:

• User: People in your institution who do work in Slate

• User (External): People outside your institution who need access to Slate

• Service Account or Service Account (Remote): Accounts for third-parties that facilitate integrations

📖 Learn how to create new users.

To be a user in Slate is one thing; but to do anything in Slate, a user must be granted permissions.

Permissions

A user’s permissions define the objects in Slate to which that user has access.

There are three types of permissions:

• System permissions: Permissions that grant access to Slate features or tools

• Exclusive permissions: Database-wide permissions intended for administrators that cannot be inherited from roles

• Custom permissions: Permissions that grant access to objects you’ve created

📖 Learn more about system, exclusive, and custom permissions.

Roles

Roles are bundles of permissions. When you give a user account a role, they inherit all of the system (not the exclusive) permissions associated with that role. Users can be assigned more than one role.

Permissions can be granted individually, but by using roles, you can sustainably manage groups of users. For example, if Faculty Advisors should all have the same permissions, create a role called “Faculty Advisors.” Assign the appropriate permissions to the role and assign the role to the user. Should the access requirements for this role change, you can manage it at the role level rather than editing each user account. Other role examples could be Gift Officer, Student Worker, or Athletics.

Populations

Access to records in Slate can be managed through Population permissions for each user account.

Users can be granted access to look up or update records that belong to specific populations rather than being granted access to look up or update all records in a database.

For example, a faculty advisor in the History department should only be able to look up and access records for History majors. By assigning population permissions, access levels to records based on population can be managed for many users in a single database.

📖 Learn more about population permissions.

Realms

While standard permissions will grant access to a given function, realms enable more targeted functional access restrictions to only objects in the realm.

📖 Learn more about realms.

Establishing your administrative user base

There’s a fine balance between having too few and too many administrative users. Create a plan to differentiate those who need extensive access from those who only need to view portals or fill out forms.

First, meet with those with decision-making responsibilities and speak to all potential users. Pose these questions to the attendees and document the following:

Who needs to:

• Build forms, events, and emails in Slate?

• See full records?

• See specific sets of data but not full records?

• See certain types of data?

• Review records and submit forms?

This process is just the beginning of the overall design. Your goal is to consider your internal operations, referring to who does what, and when and how they do it.

For example, if a user has access to manage their own Deliver campaigns but only for their one department, the “Edit All Mailings” permission could enable a user to see all mailings universally. By placing a departmental mailing into a realm, the user can edit just the mailings in their department without seeing or affecting mailings in other realms.

💡 Tip

Build in the affirmative. Consider what should a user be able to do. The granular permissions in Slate cause the things users should not do to naturally fall out of their scope.

When you provision a Clean Slate environment to view one of the model databases (such as Admissions, Student Success, or Advancement), we encourage you to navigate to the User Permissions section of the model’s Database tool. Review the types of user roles, realms, and permissions that have been created and use them as a guide to set up your user permissions plan.

Creating an organizational data map

If you have not already done so, refer to a data map of your organization’s operations. Reviewing this and inserting roles (not staff members) into the data map empowers you to understand who does what and when.

Create a document accessible to your Slate implementation team and anyone else in the jurisdiction who will have a say in deciding who should access Slate information and how they should access it.

Understand the options for setting up a new user. The following definitions are described in more detail in the related articles:

Further exploration

The members of the Slate community provide a wealth of information when it comes to shared experiences and lessons learned. Take advantage of those who have already built their user permissions.

Forums

In our Community Forums, search for posts related to user permissions, roles, and realms. Create a new post specific to your questions or organizational scenarios and allow Community Ambassadors and users to respond with recommendations and examples.

Community Conversations

Review the Community Conversation Calendar in Home Slate and look for upcoming permissions-related sessions. Submit questions in your registration form so the Client Support Engineers (moderators) can include that information in their agenda. Come prepared to speak to your user permissions plan, ask questions, and participate in the conversation, and you will leave with a clearer picture of how to move forward in building out your user permissions.

Learning Lab

Sign in to the Learning Lab and look for additional courses your team members have yet to take regarding user permissions.