Custom fields will have different configurations based on the type of data stored. This section will focus on four types of custom 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/no value

• Unique for Merging

Before configuring custom fields in Slate, carefully consider the data being captured and how it will be leveraged in Slate.

Create Free-Text Value Fields

Fields that store free-text values are generally used to collect non-standard data. If a prompt list would not effectively capture data for a particular field, then a free-text field is appropriate. Examples of this often include Explanation, Description, or Other Item fields. To create a field that stores free-text values:

1. Click the Database icon in the main navigation and select Fields.

   

   
   

2. Click New Field. The New Field popup appears. Configure at least the following:

   • Status

   • Scope Category

   • Scope - Set the appropriate scope.

   • ID

   • Name

   • Field Type
     

Click here for a complete listing of all setting descriptions.

Custom fields will have different configurations based on the type of data stored. This section will focus on four types of custom 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/no value

Before configuring custom fields in Slate, carefully consider the data being captured and how it will be leveraged in Slate.

How to Create Single Value Prompt List Fields

To create a field that stores a single value from a prompt list, enter the following Field configurations:

• Prompt - Select the prompt list to use for this  field by selecting the Prompt Key.

• Value - Important: Set the Value to 'Store Prompt ID' for all custom fields that use a prompt list configured in the Prompts tool.

• Multiple - Set this to Single Value.

Changing prompt values

Prompts can be modified at any time. Since Slate is storing the prompt ID for saved fields, the value of the prompt can be updated, and the new value will automatically be associated with the existing fields (for example, “Comp Sci/Eng” can be changed to “Computer Science and Engineering”).

If a prompt value needs to be modified in a way that alters the meaning, create a new prompt value. For example, if Art is no longer offered, but Math is a new option, do not update the Art value to Math. A better practice is to inactivate the Art prompt and make a new prompt for Math. Inactivating prompts allows you to preserve existing field values.

Custom fields will have different configurations based on the type of data stored. This article will focus on one of the four types of custom 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/no value

Before configuring custom fields, consider the data being captured and how you will use it throughout Slate.

Create Multiple Values Prompt List Fields

To create a field that stores multiple values:

1. Click the Database icon in the main navigation and select Fields.
   
   
   

2. Click New Field. The New Field popup appears. Configure at least the following:

   • Status

   • Scope Category

   • Scope 

   • ID

   • Name

   • Field Type

   • Prompt

   • Ordered - Leave the ordered setting as Unordered values. This field value should typically be set to Unordered values. Ordered values are used for fields grouped together using a replicate block.
     

Click here for a complete listing of all setting descriptions.

Replace vs. Append

You can collect information for a field that stores multiple values. Data can come into this field from various sources (for example, an advising form, an event registration form, or uploaded data). Carefully consider how a field should save data when new information is submitted. For example, an academic interests field can have the following values stored for a record:

If the field is configured to 'Replace existing values upon form submission or dataset import,' new data that comes into this field from a form submission or a dataset upload will delete any existing values and save only the most recently submitted or uploaded values:

If the field is configured to 'Append to existing values upon form submission or dataset import,' new data that comes into this field from a form submission or a dataset upload will preserve any existing values and add new values upon form submission or source import:

Single Value Field?

Custom fields configured to store a single value will always replace the value with the most recently submitted or uploaded data.

Custom fields will have different configurations based on the type of data stored. This section will focus on four types of custom 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/no value

Before configuring custom fields in Slate, carefully consider the data being captured and how it will be leveraged in Slate.

How to Create Bit Prompt List Fields

For fields with the options of Yes or No. For these fields, there is a special prompt key called bit:

• Prompt - Select the bit prompt key.

• Value - Set the Value to Store Value for a custom field using a bit prompt (or the language, state, user, or country prompt lists).

• Multiple - Set this to Single Value.

Why Not Store Prompt ID?

There are some prompt lists that save in Slate like a value. Fields using the following prompt keys must have the Value setting configured to Store Value:

• Bit (Yes/No)

• Language

• State

• Country

• User

In addition to the system IDs and GUID generated in Slate, Slate allows the creation of text fields that can hold external IDs or other record-specific values. External IDs stored in Slate enables Slate to interface with any external system.

These fields can be configured to be unique for merging and be used to merge records upon import or form submission.

The default unique for merging setting for a text field is Do not use value for merging. When set to Value contains a unique ID which identifies a single record for merging, Slate will use the value of the custom field to automatically attempt to match onto records in the dataset.

Example Unique for Merging Fields

A nine-character text field could be set as a Unique ID. If a record has the value 123456789 in this field, no other record in that dataset could have that same value. If another record were to be added to the Dataset with the value123456789 in this field, Slate would merge the existing and the incoming records.

The Consolidate Records tool will also use this field to find potential matching records. Configuring unique fields is important when uploading data from external systems (for example, unique system IDs) into Slate.

A custom field should only be configured as unique if each record is guaranteed to have a unique value for the field. Examples of unique custom fields include:

• SIS ID 

• Banner ID 

• EmplID

Custom fields will have different configurations based on the type of data stored. This article will focus on one of the four types of custom 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/no value

Before configuring custom fields, consider the data being captured and how you will use it throughout Slate.

Fields that Store a Single Value from a Prompt List

Custom fields will have different configurations based on the type of data stored. This section will focus on four types of custom 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/no value

Before configuring custom fields in Slate, carefully consider the data being captured and how it will be leveraged in Slate.

How to Create Single Value Prompt List Fields

To create a field that stores a single value from a prompt list, enter the following Field configurations:

• Prompt - Select the prompt list to use for this field by selecting the Prompt Key.

• Value - Important: Set the Value to 'Store Prompt ID' for all custom fields that use a prompt list configured in the Prompts tool.

• Multiple - Set this to Single Value.

Changing prompt values

Prompts can be modified at any time. Since Slate is storing the prompt ID for saved fields, the value of the prompt can be updated, and the new value will automatically be associated with the existing fields (for example, “Comp Sci/Eng” may be changed to “Computer Science and Engineering”).

If a prompt value needs to be modified in a way that alters the meaning, create a new prompt value. For example, if Art is no longer offered, but Math is a new option, do not update the Art value to Math. A better practice is to inactivate the Art prompt and make a new prompt for Math. Inactivating prompts allows you to preserve existing field values.

Fields that Store a Yes/No Value (Bit Prompt)

Custom fields will have different configurations based on the type of data stored. This section will focus on four types of custom 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/no value

Before configuring custom fields in Slate, carefully consider the data being captured and how it will be leveraged in Slate.

How to Create Bit Prompt List Fields

Important!

No Yes/No Prompts! Do not make Yes/No prompts in the Prompts tool. Without exception, a bit prompt is the best way to store this data.

For fields with the options of Yes or No. For these fields, there is a special prompt key called bit:

Unique for Merging

In addition to the Person and Application scoped system IDs and the record GUID generated automatically in Slate, Slate allows the creation of custom text fields that can hold external IDs or other unique record-specific values. External IDs stored in Slate can be used to match to records on import and via forms and play a critical part in integrations.

The default unique for merging setting for a text field is Do not use value for merging. When set to Value contains a unique ID which identifies a single record for merging, Slate will use the value of the custom field to match onto records in the dataset.

To create a Unique for Merging field, create a Text field using Field Editor, then update the Unique for Merging Setting to Value contains a unique ID which identifies a single record for merging.

Example Unique for Merging Fields

A nine-character text field could be set as a Unique ID. If a record has the value 123456789 in this field, no other record in that dataset could have that same value. If another record were to be added to the Dataset with the value123456789 in this field, Slate would merge the existing and the incoming records.

The Consolidate Records tool will also use this field to find potential matching records. Configuring unique fields is important when uploading data from external systems (for example, unique system IDs) into Slate.

A custom field should only be configured as unique if each record is guaranteed to have a unique value for the field. Examples of unique custom fields include:

• SIS ID 

  • Banner ID 

  • EmplID 

  • ColleagueID

  • CommonApp ID 

  • Questbridge ID

⚠️ Caution!

Be careful when mapping a data import to multiple unique for merging fields: the import can use any of the unique for merging fields to match a candidate application or person.

Similarly, collecting values publicly (that is, through a public-facing form) to unique for merging fields can result in record collisions if transcription errors occur. 

Please refer to the following articles for further information on how matching criteria and ordering works:

• Matching Criteria for Application Records

• Matching Criteria for Person Records

• Matching Criteria for System Objects