Considerations for Administering Student Success and Admissions in a Shared Database

Leveraging Slate for both admissions and student success processes offers a considerable advantage. You can use the abundance of student data from the admissions cycle and collect additional data on enrolled students.

Valuable information collected in Slate during the admissions process, such as extracurricular interests, communication preferences, and other key data points, can be used by student success staff to make informed decisions and customize engagement with students. The admissions office can offer insights to advising and student success staff as they continue to communicate with enrolled students.

Institutions sharing a Slate database for admissions and student success should have conversations about the following topics early on in the process:

Record Separation

Record management is one of the fundamental steps for maintaining a shared database. One of the first high-level strategies to consider is separating prospects and applicants from enrolled students. One solution is to add a status of "enrolled" or "current" to the three existing person statuses of prospect, inquiry, and applicant in Slate. Creating corresponding person status rules ensures that the desired records will be included in various business processes.


Given the potential sensitivities around enrolled students, it is important to consider user, object, and record access early in the implementation process to ensure a strategy is in place for handling these two cohorts. Slate provides the ability to control users' access, object access, and record access in a manner that allows each institution to control with granularity just how closely the different departments (admissions, student affairs, athletics) operate. For example, permissions can be granted to view the information displayed on a student's record.

Institutional Culture and Communication

Evaluating how well your student success and admissions teams work together and communicate is important. Are you in regular contact? Do you share similar business practices? Does each group trust the other to work in an environment where data is shared, updated, or exported? If your teams work in conjunction with each other, then sharing your instance may be the right choice.

Branding and Slate Database URL

Branding sets the look and feel of your database to people interfacing with forms, portals, and applications. If you have a current admission instance of Slate, it is likely branded for your admissions department. You can take steps to change some of the branding for student success by your marketing team, but you may wish to change/create the overall branding of your site to something broader and not admissions or student success-focused. If you have a current admissions Slate instance, it will have an established URL, such as, which you can change or update to be inclusive of student success.

We recommend that you speak with your IT staff to see your options in creating a new student success URL that could be forwarded to the existing Slate database.

Data Integration

Many institutions transfer data bidirectionally between Slate and their institutional SIS and between Slate and other databases as needed. File transfer via SFTP or RESTful web services is employed for such integration. Laying out what data points you would like Slate to house and from which system they are received is important to consider while sharing a database. In addition to the SIS, you may need data points from an LMS, Financial Aid System, or other databases across campus. Proper data integration can ensure the appropriate data is accessible in Slate (or another system) at the right time.

Default Email Address

Each Slate database allows one programmed ‘Reply To’ email, set on all email communications, such as or You can manually insert other Reply To email addresses when crafting new messages, but discussing the default email address is necessary.

Folder Naming Convention

When using one Slate database to house admissions and student success, you will want to review your folder naming conventions, so they work for both teams. You can add identifiers to your folders, such as ADM or SSA, to help distinguish which folders contain the items your respective teams need.


If you are planning on assessing payments due in your shared instance of Slate, you can evaluate which payment service your admissions and student success staff are using and if one provider can meet your needs. Slate can be configured to use multiple payment processing services; however, consolidating to one can be helpful to streamline your business practices.

New Feature Releases

Slate is a feature-rich CRM that changes every day. Major changes are often released but need to be activated in the database by your Slate administrator(s). When new functionality is set to be used by an admin, it is available globally to every user. Communication regarding feature releases between departments is crucial so all users know about a forthcoming product change.

Timeline Tab

One of the best ways to see the history of a student record is to view the Timeline tab. This tab summarizes all interactions, communications, data uploads, and more. There are some areas of Slate where posts to the Timeline tab can be hidden, such as source files when importing data and email communications. However, all items on the Timeline are visible to all users with access to that tab. You can remove access to that tab on a user-by-user basis if desired. A combined instance would allow admissions and student success staff to view all available Timeline tab items.

Person Status Rules

In a typical admissions Slate instance, the Person Status rules are set to one of three choices: Prospect, Inquiry, or Applicant. If you share an instance of Slate, you can add a fourth status choice of Matriculated or Enrolled to help identify the student as actively taking classes on your campus. This would require an additional rule in the Rules tool to help set this option.

Authentication and Single Sign-On

If you are considering housing admissions and student success information in your Slate database, you can change the method used when a student is logging into Slate once they have matriculated. You can set up Slate to use stand-alone usernames and passwords for students applying to your organization and then use your institutional single sign-on for your matriculated students. They can receive an official user ID with your other university systems. You can find additional information on how you can accomplish this here. We recommend you share this document with your information technology staff to help begin the conversation about this service.

Service Desk and Training

With the purchase of a Slate database, three 'captains' are designated to submit service requests to Technolutions when needed. If you are interested in sharing an instance, you will need to figure out who those captains should be (two from Admissions, and one from Student Success, for example). When the original contract is signed, online training is offered to those three captains. If you wish to train additional student success staff or admission staff, an additional cost would be assessed of $250 per user.


We encourage our student success and admission clients to help continue building this list. If you have additional items which may have come up during your decision-making process, please let us know so we can add them to this article.

Was this article helpful?
6 out of 6 found this helpful