Considerations for Administering Student Success and Admissions in a Shared Database
  • 23 Apr 2024
  • 6 minute read
  • Dark
    Light
  • PDF

Considerations for Administering Student Success and Admissions in a Shared Database

  • Dark
    Light
  • PDF

Article summary

Using 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.

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

Institutions sharing a 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.

Permissions

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 database might 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 database, 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 database, it will have an established URL, such as www.applynow.university.edu, which you can change or update to include student success.

We recommend that you speak with your IT staff to see your options for creating a new student success URL that could be forwarded to the existing 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 store and from which system they are received is important to consider while sharing a database. In addition to the SIS, you might 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.

Profile Tab

Each student record in Slate comes with a Profile tab which allows for storing and displaying multiple data points such as schools, scores, jobs, courses, interests, and sports. In an admissions database, these tables are typically used to record data for a prospective student - high school sports, jobs, and activities - but not for a currently enrolled student in your organization. With a separate database for student success, you can more easily identify currently enrolled student data and use the Profile tab without combining legacy admission information. 

The separation of databases would require your staff to move relationship, address, and contact information from your admissions database into your new student success database if you wish to create enrolled student records with this data available for use.

Default Email Address

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

Folder Naming Convention

When using one database to store 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.

Payments

If you plan to assess payments due in your shared database, you can evaluate which payment service your admissions and student success staff use 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 administrators. When new capabilities are 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 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 database would enable admissions and student success staff, with permission to see the Timeline tab, to see any/all items on that tab which have not been expressly hidden. 

Person Status Rules

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

📖 Further reading

Automating the enrolled student status

Automations, Queries, and Reports

Your staff may wish to review established admissions rules, queries, and reports to ensure that student success records and data points are excluded where needed. As an example, if you use an application for on-campus employment in your shared database, but have existing application checklist rules set to create checklist items on all admission applications, you would want to ensure the student success applications would be excluded from those rules to help avoid admissions checklist items displaying on student success applications. The same review process should be taken for all rules, reports, and queries.

Authentication and Single Sign-On

If you are considering housing admissions and student success information in your database, you can change the method used when students log 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 (SSO) for your matriculated students. The Single Sign On Knowledge Base article provides additional information on implementing SSO. We recommend you share this document with your information technology staff to help begin the conversation.

Training - Fundamentals of Slate

Three complimentary Fundamentals of Slate course registrations are provided with each database. If you choose to share an instance with admissions, registration for these courses costs $250 per person if all three waivers have been used. Details are available in the Learning Lab Courses Knowledge Base article.

Support Desk

With the purchase of a database, three "Captains" are designated to submit support tickets to Technolutions when needed. If you are interested in sharing a database, determine who those Captains should be (two from Admissions, and one from Student Success, for example).

 

 

 


Was this article helpful?