Organization Contacts Dataset Overview
- 08 Nov 2023
- 7 minute read
- Print
- DarkLight
- PDF
Organization Contacts Dataset Overview
- Updated 08 Nov 2023
- 7 minute read
- Print
- DarkLight
- PDF
Article Summary
Share feedback
Thanks for sharing your feedback!
Every Slate database is provisioned with an existing organization contacts dataset and is considered the child dataset associated with the organizations dataset. This dataset is used to manage individual persons associated with an 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:
When should we consider introducing this functionality to our organization contacts dataset?
This project should begin after the initial implementation of the Slate database, since there are advanced skills covered in this article that require fundamental knowledge and a clear understanding of the business processes already established within the database. In addition, this project should be scheduled during time typically reserved for special projects, because it will take a couple of weeks to complete, and the task may require support.
Slate Standard Fields and Prompts
Slate uses a number of standard fields, which are uniform across all admissions 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.
Field | Description |
|---|---|
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 protected]). |
Device Type | The device types for organization contacts are the same device types used for person records. The standard device types are:
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
Field | Description |
|---|---|
Key | The unique identifier for each dataset record. |
Name | This is the Display Name listed at the top of the record. The first and last names are stored in separate fields. |
Pre-Delivered Custom Fields
The following delivered custom organization contacts fields and prompts are pre-loaded into the database:
Field | Description |
|---|---|
Salutation | This field uses the same prefixes as the salutation field on the person record. |
First | Organization contact first name. |
Last | Organization contact last name. |
Relation | Relationship type. To customize the prompt list below, use the prompt key contact_relation. The pre-delivered prompts are:
|
Title | This text field stores the job title of the organization contact. |
This custom field is separate from an email stored on the standard device table. The custom email field is used as the unique for merging field, to match on an existing record or to create a new record from data entry or import. A rule can be created to copy the rank 1 email address from the device table to this field. Refer to the Matching Criterial section of this article and the Matching Criteria for Dataset Records article to view more information and to determine if this custom field will be used or inactivated. | |
Phone | This custom field is separate from a phone number stored on the standard device table. This custom field is a legacy field and may be inactivated. |
Display Name | This field assists with the creation of filters and exports for the display name. It should not be altered. For additional information on automating the pre-fill of this field with the first and last name fields, refer to Organization Contacts Display Name Rule. |
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. Create custom fields for the organization contacts dataset. Organization contacts must be selected from the dataset drop down setting and their scope must be set to "Person."
Tip
Most institutions do not need to create many, if any, custom fields for their organization contacts dataset.
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 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.
Tip
Many institutions have found that of all data collected from an organization contact, the value of an email address is the most unique (and easily remembered by the contact when filling out a form).
Unique for Merging Field Rule
When an Organization Contact’s email address is updated in the device table, it is beneficial to have a rule to update the unique for merging field as well, to ensure that future form responses or uploads match to this record. A rule can be created to update the unique for merging field with the current Rank 1 email of the record.
Use the following procedure to create the organization contacts unique for merging field rule:
Select Database on the top navigation bar and select Rules Editor.
Select New Rule.
Enter the following configurations in the dialog box:
Name: Organization Contacts Update Unique for Merging Field
Base: Configurable Joins - Organization Contacts
Type: Field
Non-deterministic: Rule is deterministic and has an exclusive priority
Select Save.
Note
Filters should not be added to this rule.
Configure the appropriate action
Field: Email
Action: Replace Values from Formula
Export: Add the export for Value from the Device Details by Type, Rank export block:
Configure the export by selecting the type of Email Address, Rank of 1 and renaming the export to "email."
Formula: @email
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.
Tip
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 the rule. This ensures if staff need to update the email address of a record, they update the email in the device table, which then updates the unique for merging field 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 381178. The parent key of the organization contact will be the CEEB code of the organization with which the contact is associated.
Setting a Parent Key on an Organization Contact Record
Go to the profile tab for the organization contact record and select Account.
Search for the organization from the Parent Records field (an autosuggest list from the organizations dataset appears).
Setting a Parent Key on a form or in Upload Dataset
On a form or in Upload Dataset "Parent Key" is a destination that can be mapped as follows:
Best Practice
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.
Was this article helpful?
