Your first order of business: configuring essential objects where they already exist, building them out where they don’t.

What’s already built

When your database was provisioned, it came from one of two templates:

• the 4 Year & Graduate Admissions model,

• the 2 Year/Community College model, or

• the K12 School model

You’ll have a different set of pre-configured objects in your database depending on the template. We make note of which objects already exist in each model throughout the Roadmap.

📝 Many of these objects require configuration before they’re ready to use.

If you see something you like in the other model, use the linked documentation to build it in your database. Or, check the Slate Showcase environment for a pre-built example that you can import into your database using Suitcase.

Initial configurations

There are a few high-level settings to check off your to-do list immediately.

Configuration keys

Configuration keys control database-wide settings. Updating them later can have far-reaching impacts, so it’s best to adjust them early.

There are a lot of configuration keys. Not all of them apply to you (or are intended for your use). However, some keys are for use in emergencies, like Emergency Stop, which halts all non-transactional communications. It’s good to be familiar with what’s available before you need it.

Keys most often adjusted by new schools include:

• Organization Name: Double check that this appears as you want it.

• First Day of the Week: Defaults to Monday.

• Default Sender Email: For example, [email protected].

• Default Mailing Template: Optional. Can be set once you’ve created mailing templates in Deliver.

▶️ Action item

Review the Configuration Keys document, looking for any settings that you may need to change from their defaults—items from the list above, or things you know your institution does differently

✨ Ask the Community if you have any doubt whether you should update a key.

DKIM

Setting up DKIM (DomainKeys Identified Mail) tells email servers that emails originating from your school are legitimate and not from a spammer. This is a quick item that pays dividends by making your communications as deliverable as possible.

▶️ Action item

• Set up DKIM

Default unsubscribe group name

Message groups let you define the types of communications that students can choose to opt out from.

The default message group’s unsubscribe group is called Slate University.

▶️ Action item

To change this value to your institution’s name:

1. From the main navigation, select Database.

2. Select Message Groups.

3. Select the default Allow Unsubscribe group.

4. In the Unsubscribe Group field, enter your institution’s name.

5. Select Save.

Users and permissions

User accounts and their associated permissions determine who has access to Slate and what they can do with it.

Only users with the Security Administrator permission can add new users, deactivate existing users, and manage other users' access.

Roles

The following roles exist by default in your database:

• Academic Advisor

• Admission Counselor

• Admissions Inbox

▶️ Action items

• Customize the existing roles (Academic Advisor, Admission Counselor, and Admissions Inbox) as needed.

• Create additional roles and permissions.

Population permissions

Population permissions determine which records are accessible to each user. Schools managing a shared graduate-undergraduate database can restrict users to only the graduate or undergraduate populations, or to specific programs within a graduate population.

▶️ Action item

• Establish population-based permissions.

✨ Tip: Restrictive permissions impede new operations and frustrate new users. You can always add restrictions later if they prove necessary.

Realms

Realms add another layer of access control to Slate objects. When a realm is associated with an object, only those users with both the appropriate permissions for that object type and the realm are granted access.

▶️ Action items

• Add realms to your database.

• Enable multi-factor authentication.

Users

Your database comes with placeholder users. These users are the target of staff assignment rules in your database, which we’ll get to later in this article.

▶️ Action item

• Add users, manually or by import.

The person record

The person record is at the heart of many administrative processes in Slate.

The person record has a dashboard and tabs, both of which are highly customizable.

Use this early stage in your implementation to get familiar with the options and functionality available to you on the student record. You don't need to finalize its configuration until you have more experience working in Slate.

Test record

Alexander Hamilton is the default test record in your database. Feel free to create more test records that incorporate diverse data points.

Person dashboard

The person dashboard includes two data objects by default: an entry term tile and a staff assigned tile.

To edit the dashboard, go to Database > Dashboards and select Person Record - Inquiries & Applicants.

▶️ Action item

• Learn how to customize the person record dashboard.

Custom tabs

This record, and any subsequent records you create, features a custom tab called More Information. It’s meant to demonstrate the functionality of custom tabs.

2 Year/Community College Model: the Academic tab

2 Year/Community College model databases include another custom tab, Academic. This tab includes enrolled student information, like credits completed, cumulative GPA, and more.

You can update these custom tabs to include different data, or create new custom tabs entirely.

You can find the tab in Database > Tabs. Select More Information from the list to configure its settings.

Find the form that supplies the data in Forms > Custom Tabs. Select Person Details Tab from the list to configure the data that appears.

▶️ Action items

• Update the information on the custom tab.

• Customize the standard person record tabs.

Interactions

Your database comes a number of pre-configured interactions that can be used to populate the student record’s timeline. With the exception of the Watch Flag interaction code, these are system interactions and can’t be modified.

Watch Flag is a custom interaction, and you can create more of your own.

To create or modify a custom interaction, go to Database > Activity & Interaction Codes.

You can add your custom interaction to a student record to notify other staff about something that has changed about the record, or an event that occurred.

To add an interaction to a record, select Timeline > New Interaction. Select a Code from the list.

▶️ Action item

• Create custom interactions.

Tags

Tags are data indicators that are highly visible on the student record.

Your database comes with two tags by default: Opt Out and Test Record.

To add or modify tags, go to Database > Tags.

▶️ Action items

Fields and prompts

Slate data is stored in fields (the labels that describe what kind of data it is) and prompts (values that the data can be).

As a refresher, there are four types of fields:

• Fields that store free-text values

• Fields that store a single value from a prompt list

• Fields that store multiple values from a prompt list

• Fields that store a yes or no value (also known as bit values)

Scope

Fields have a scope that determines the relationship between the data it stores and the types of records in your database.

For example, the Person scope tells the database it can treat data stored in the field as if it was stored on the person record.

Standard fields

Slate has standard fields. They exhibit special behaviors behind the scenes that make them distinct from custom fields.

🔔 You don’t need to—and should not—recreate standard fields.

The standard field IDs are:

• name

• first

• last

• middle

• preferred

• prefix

• suffix

• sex

• resident

• phone

• business

• mobile

• email

• birthdate

• ssn

• ref

📖 Further reading: Learn more about standard fields.

Custom fields

To manage any data not available among the Slate standard fields, create custom fields.

We include some common custom fields in your database by default. To access them, and to create your own, select Database > Fields.

▶️ Action items

• Review field settings.

• Go through your model’s custom fields (listed below, available in Database > Fields). Make adjustments to suit your process.

• Create custom fields.

✨ Tip

Refresh the cache on Fields, Prompts, Slate Template Library, and Configurable Joins Library to immediately access new entries.

Custom prompts

As with fields, there are also custom prompts in your database. To access them, select Database → Prompts.

▶️ Action items

• Review prompt settings.

• Go through your model’s custom prompts (listed below, available in Database → Prompts). Make adjustments to suit your process.

• 🔔 Important: Replace placeholder values for entry_term in 4 year models and K-12 models, term in 2 year models.

Forms

Forms can create or update records, and they can collect data using both standard and custom fields. The scope of the form determines which records are created or updated.

Pre-configured forms

4 Year & Graduate Admissions model database

• Application Creation Form

• Application Details Tab

• Decision Management: Reply to Offer of Admission

• New Organization Contact Form

• Person Details Tab

• Reader Review Form

• Request for Information

• School Report Page

2 Year/Community College model database

• Academic Tab

• Advising Note Entity (Widget)

• Application Creation Form

• Application Details

• Decision Management: Reply to Offer of Admission

• Declaration of Major

• Early Alert Entity (Widget)

• Early Alert Form

• Early Alert Workflow Form

• New Organization Contact Form

• Notes Tab

• Reader Review Form

• Request for Information Form

• Workflow - Early Alert Form

K-12 School model database

• Application Details Tab

• Decision Management: Reply to Offer of Admission

• New Organization Contact Form

• Person Details Tab

• Reader Review Form

• Request for Information

• School Report Page

Note also that there are a number of application-page-scoped forms in your database.

📖 Further reading: Creating a form

Request for information form

The first form you’ll likely want to configure is your request for information (RFI) form. Since it saves data on the person record, this form is scoped to person.

▶️ Action items

To access these form communications, select Edit Communications on the form overview page.

📖 Further reading: Form communications

Matching criteria

To prevent duplicate records from being created if the same person fills out the form twice, Slate will evaluate matching criteria between the form submission and existing person data.

📖 Further reading: Matching criteria

Origin sources

When a prospect interacts with your institution for the first time, Slate can classify them with an origin source, or the channel that they used to reach you.

By default, your database includes the following origin sources, separated into the following groups:

• Events

  • Event Template (Interview)

  • Event Template (Event)

• First Source

  • All Events

  • All Forms

  • All Interactions

  • All Interviews

  • All Materials

  • All Source Formats

  • All Stealth Applicants

  • All Tests

  • Slate.org

▶️ Action items

• Brush up on the ways origin sources can be put to use for reporting.

• Add any additional origins to your list as needed.

Queries

As you learned in Fundamentals, the query builder is arguably the most important tool in Slate.

Among others processes, queries are involved in:

• Batch managing records

• Scheduling data exports

• Defining audience lists for communications

• Assigning populations to be affected by automations

• Releasing decisions

Pre-configured queries

Your database includes a number of queries already, depending on the model it was provisioned from.

Access these queries by selecting Queries / Reports from the main navigation, then selecting All queries.

These queries demonstrate the range of functions that queries are capable of: the same tool that finds all of your applicants for reporting can export documents to a third-party system, like your SIS.

▶️ Action items

• Familiarize yourself with the query elements.

• Explore the pre-configured queries and create more to suit your needs.

• Configure the following queries before use:

Configure the Data Export - SFTP (Slate to SIS) query

We include data that most institutions send to their student information systems, but you may need to add or remove exports.

Later in the Roadmap, when you’ve completed your SIS integration, you’ll activate the Schedule Export status and configure a method for the data transfer, whether by SFTP or Web Services.

See Exporting Data Overview for more information.

Configure the Document Export query

As with the data export query, you may choose to export different data points in your document export.

Later in the Roadmap, when you’ve completed your document management system integration, you must configure the query for scheduled export.

See Document Export Query for more information.

Configure the Voyager: Domestic Travel Planning query (4 Year model only)

Voyager is a reporting tool in Slate that you’ll become familiar with later, during Roadmap Stage 6: Reporting.

For now, take a look at the pre-configured Voyager Domestic Travel Planning query by selecting Voyager from the list at right.

Explore the data layers available, and poke around in the queries that generate them. Take note of areas where your reporting process differs from what’s provided.

📖 Further reading: Voyager

Automation

Most processes in Slate involve rules in some capacity.

Because rules have the ability to impact thousands of records at a time, you must test them thoroughly.

Rule groups

Your Slate for Admissions model database comes with nine rule groups. Rule groups are also called exclusivity groups.

An exclusivity group lets you filter against a record as if you were executing multiple different queries at the same time, then prioritize which action should be taken on the record.

📖 Further reading: Exclusivity Groups

The groups are separated by scope, or the type of records the rules in the group affect. The pre-configured rule group scopes include: application, person, organization contacts, and organizations.

We’ll get to application rules later, when we start dealing with application data. For now, focus on the person-scoped rule group.

Person header rule

This rule generates the person record information (Ref ID, birthdate) that appears in search results.

It uses a formula, 'Ref ID: ' + @ref + isnull(', DOB: ' + @Birthdate , ''), to pull these two data points into the search results.

▶️ Action item (optional)

This rule doesn’t need to be configured to run, but if you want to change the data it displays, see Customizing Person Record Search Criteria with Person Index/Header Rules.

Person status rules

Your database comes with rules that set the person status (prospect, inquiry, or applicant) on all person records.

▶️ Action item (optional)

Add new person status rules as needed.

Staff assignment rules

Your database comes with a Staff Assignments exclusivity group.

By default, staff assignment rules automatically associate applicant records with a staff user record based on the applicant’s geographic data:

▶️ Action item

Update these placeholder rules based on your staff assignment criteria.

Edit the filter criteria to change the applicant records assigned in each rule:

Add users to your database, then select them from the prompt list in your staff assignment rules.

Alternatively, delete the default staff assignment rules and create your own.

Population rules

There are two default populations in your database, accessible in Database > Populations.

Populations are labels for types of records. Population rules move records into these populations.

You can then target these populations in drip marketing efforts: populations appear as campaigns in Deliver:

We’ll get to Deliver later on. For now, it’s enough to know that you can create more populations and population rules if you have large groups you know you’d like to target with your drip communications.

📖 Further reading: Populations

Branding

Start your branding journey by updating the default “Slate University” branding. Your branding is likely highly specific to your institution: we recommend reaching out to the Community Forum for custom branding questions.

📖 Further reading: Branding in Slate

🔔 Important!

Any custom scripts or other non-Slate code must be maintained by your institution, and we cannot guarantee support of the custom code if problems are encountered.

▶️ Action item

Update the default “Slate University” branding.

Other data structures

Configurable data structures in Slate like translation codes, entities, and custom datasets lets you broaden and deepen the content of your database.

• Datasets let you manage other primary records in your process just as you manage person records. Datasets for Organizations and Organization Contacts are already available in your admissions database.

• Translation Codes transform or combine data values.

• Entities create custom scopes.

It’s not required that you create anything with these data structures now, but they are worth exploring and incorporating into your plans, especially for instances where Slate doesn’t yet have a pre-configured data object to represent what you’re after.

📖 Further Reading

• The Organization Dataset

• Custom Datasets

• Translation Codes

• Entities

Next up: Outreach

Everything you’ve created or configured so far have been the foundational structures of your Slate database.

Now, we tackle the next most important component: communications.

➡️ Next: Step 2: Outreach