Slate for Admissions and Slate for Student Success databases are provisioned with two standard datasets:

• The Organizations dataset, which includes more than 50,000 institutions with CEEB codes

• The Organization Contacts dataset, the child dataset of Organizations, which may be used to store information about individuals associated with a given organization.

This article offers best practices to manage and enhance the standard organization contacts dataset.

In addition, be sure to read the following articles regarding the initial configuration of this dataset:

• Organization Contacts Display Name Rule

• Migrating Custom Organization Contact Emails & Phone Fields

Slate standard fields and prompts

Slate uses a number of standard fields, which are uniform across all databases, to store data in the organization contacts dataset. Every provisioned database includes the following delivered standard organization contacts fields and prompts:

Contact

Similar to a person record, dataset records can utilize the device table to store multiple email addresses and phone numbers.

Device value

This field stores the value of the device, such as a phone number or email address (for example, 555-867-5309 or email@email.com).

Device type

The device types for organization contacts are the same device types used for person records.

The standard device types are:

• Email Address

• Primary Phone

• Mobile Number

• Evening Phone

The device type prompt list on the contact table can be customized.

🔔 Important!

The email addresses and phone numbers stored on the device table are separate from the custom, pre-loaded custom email and phone fields. Refer to the Pre-Delivered Custom Fields section of this article for more information on the purpose of the custom email and phone fields. Email addresses stored on the device table allow for the display of email communications on the record timeline.

Addresses

Similar to the person record, dataset records can use the address table to store mailing and permanent addresses. It is possible to store address information for organization contacts. However, it this is uncommon practice, since most organization contacts receive mail at their organization. When querying for organization contacts, the address information for the associated organization is available.

Other

Pre-delivered custom fields

The following delivered custom organization contacts fields and prompts are pre-loaded into the database:

Creating Custom Fields

As with person records, custom fields can be created for data points that are essential to various business processes for which a Slate standard field does not exist. For example, an "Alumni" field might to be used to store information about organization contacts that also attended your institution.

To create custom fields for the organization contacts dataset:

1. Select Database on the top navigation bar.

2. Select Fields.

3. Insert a new field with the following settings:

   • Scope Category: Records

   • Scope: Organization Contacts

   • ID: Provide a unique field ID

   • Name: Give the field a descriptive name

   • Field Type: For a description of the available options, see Field Settings.

Most institutions do not need to create many, if any, custom fields for their organization contacts dataset, with the exception of a unique for merging field.

Matching Criteria

While the records in the organization contacts dataset represent people, it is important to remember that they are not person records, and therefore the records do not inherit matching criteria. Person records match on first name, last name, birth date, and email, while dataset matching criteria must be established with either a key or with a unique-for-merging field.

It is best practice to create a dataset row key and/or a unique for merging field for every dataset. This key and/or field is used in Upload Dataset and upon form submission to match new records to existing records. In addition, matching criteria allow for updating of records and prevent creating duplicate records. Without a dataset row key and/or a unique field, all entries will create new records.

The organizations dataset is pre-delivered with CEEB as the key, since this data point is a unique identifier for each organization record. When the Slate database is provisioned, the organization contacts dataset is not pre-delivered with a key or a unique for merging field. As noted above, without a dataset row key and/or a unique field, all entries will create new records.

Unlike organizations, which have a publicly known unique identifier (CEEB code), there is no universal, standard unique identifier for organization contacts.

Many institutions have found that of all data collected from an organization contact, the email address is the most unique (and easily remembered by the contact when filling out a form).

Create a unique for merging field

1. Select Database on the top navigation bar.

2. Select Fields.

3. Insert a new field with the following settings:

   • Scope Category: Records

   • Scope: Organization Contacts

   • ID: Provide a unique field ID

   • Name: Give the field a descriptive name

   • Folder: Place organization contact fields in a folder to keep them organized.

   • Field Type: Free Text.

   • Unique for Merging: Select Value contains a unique ID which identified a single record for merging.

     • For a description of the field options, see Field Settings.

4. Select Save.

Rule to set unique for merging from contact email

When an organization contact’s email address is updated in the device table, it is recommended to have a rule update the unique for merging field to ensure that future form responses or uploads match to this record rather than creating a new record.

Use the following procedure to set the organization contacts unique for merging field to the value of rank 1 email address:

1. Select Database from the main navigation.

2. Under Automations, select Rules.

3. Enter the following configurations:

   • Name: Give the rule a name (such as "Organization Contacts Unique For Merging Field").

   • Type: Select Configurable Joins.

   • Category: Select Records.

   • Base: Select Organization Contacts.

   • Rule Type: Select Name.

   • Folder: Place the rule in a folder to keep organization contact rules organized.

   • Status: The rule can be set to either Inactive or Preview.

4. After saving the rule, add any necessary filters to the rule. Since every organization contact should be affected by this rule, no filters need to be added.

5. Under the Action section of the rule, configure the following:

   1. Field : Select the custom field you created (“Contacts Unique for Merging”).

   2. Action: Select Replace Values from Formula.

   3. Under Exports, add the following configurations:

      • Add a Join from Organization Contacts to Device by Type, Rank. Configure the join to Type of Email Address, Rank of 1, and Save.

      • Add an Export for Device Value from the join you created. Since this export will be used as a variable, give it a friendly name (like “Email”).

   4. In the Formula box, type @ to see a dynamic list of available variables. Select the export added in the previous step, for example @Email. The formula should contain only this variable as the goal is to set the unique for merging field to match this value.

6. Save the rule.

Why are we storing email in two places?

Since the organization contact's email address is being used as both their email address and their unique for merging field, it will need to be stored in two places: the email address device type and the custom unique for merging field. Both of these destinations will also need to be mapped on forms and in Upload Dataset.

Since the email is stored in two places, the device table and the unique for merging email field, it may be beneficial to remove the unique for merging email field from displaying on the Details tab and only update this field via forms, uploads, and via the rule. If staff need to update the email address of a record, the correct procedure is to update the email in the device table, allowing the unique for merging field to be updated via the rule.

Parent key

The organization contacts dataset is the child dataset of the parent organizations dataset. To successfully connect an organization contact record to an organization, the parent key must be used. For example, guidance counselor Diana Prince (Organization Contact record) works for Reynolds High School (an organization record), which has a CEEB code of 391583. The parent key of the organization contact will be the CEEB code of the organization with which the contact is associated.

Setting parent key directly on an organization contact record

1. Go to the profile tab for the organization contact record and select Account.

2. Search for the organization from the Parent Record field. An autosuggest list from the organizations dataset appears, allowing the user to search by name, location, or by CEEB code.

3. Select the desired parent record and Save.

   

Setting parent key on forms

See Organization Contact New Record Form for the correct mapping, using School Name Search auto-suggest capability to set the corresponding School Key value as the Parent Key on the new record.

Setting parent key for imports via Upload Dataset

On a form or in Upload Dataset "Parent Key" is a destination that can be mapped as follows:

In addition to parent key, there is also a destination of "Parent Name (for record creation)." This destination should ONLY be used when the intention is to create new organizations in your Organizations dataset. It is uncommon to map to this destination, and is strongly discouraged on forms that will be filled out publicly.