User accounts represent individuals who can access your Slate database, while the permissions assigned to those accounts define the actions they are authorized to perform.

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.

Having a user account in Slate provides access to the system; however, the ability to perform actions within Slate requires that appropriate permissions be granted.

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 in Slate

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

Roles

Roles are a collection of permissions.

When you give a user account a role, they inherit all of the system (but 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

Design permissions with an affirmative approach by focusing on what users should be able to do. Because Slate permissions are highly granular, actions that users should not perform will naturally fall outside their assigned 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, consult a data map of your organization’s operations. Reviewing the map and inserting roles—rather than individual staff members—will help clarify responsibilities and when specific activities occur.

Create a document that is accessible to your Slate implementation team and other relevant stakeholders responsible for determining who should have access to Slate information and how that access should be granted.

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

Further exploration

The Slate community offers a wealth of shared experiences and lessons learned. Consider leveraging insights from institutions that have already established their user permission structures.

Forums

In our Community Forums, search for posts related to user permissions, roles, and realms.

Create a new post in the Community Forums focused on your user permission questions or organizational needs, and invite Community Ambassadors and other users to provide 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 discuss your user permissions plan, ask questions, and actively participate in the conversation. Doing so will provide you with a clearer understanding of how to proceed with building your user permissions framework.

Learning Lab

Sign in to the Learning Lab to explore additional courses on user permissions that your team members have not yet completed.