- 23 Apr 2024
- 10 minute read
- Print
- DarkLight
- PDF
Creating a Custom Field
- Updated 23 Apr 2024
- 10 minute read
- Print
- DarkLight
- PDF
Custom fields enable you to complement the many standard fields in Slate with fields that capture data specific to your business process.
Some examples of custom fields and the data points they might store are:
A desired major such as art history, mathematics, or political science
A constituent type such as LYBUNT, SYBUNT, or current donor,
A visa type such as F-1 or J-1.
The relationship of fields to different objects in the database is very important, and the scope of a field defines this relationship. For example, a custom field that stores the visa type would be applicable to Person records, and thus would have a "person" scope. A custom field that stores a fund type, such as a restricted or unrestricted fund, would be related to the Funds dataset and be scoped to the fund's dataset. There isn’t always a clear-cut answer for which scope is the best for your field; you’ll need to make a decision based on your institution’s processes and needs. For example, a custom field that stores a desired major might be Person-scoped or Application-scoped, depending upon whether you want to treat that information as specific to the Person or specific to their Application.
Fields can store data as either free text or a value selected from a list. When a field uses a select list, the available values are called "prompts" in Slate.
The type of data stored in a field configured for free text should be unique enough not to be considered a part of a list. Some examples of this type of data include unique IDs, highly-personalized information (such as a favorite book), paragraph text (such as notes or essays), and dates.
Prompt lists are useful for restricting values to selectable options. Fields that use prompt lists can be configured to store either multiple values for each record or a single value per record. This makes data entry more manageable, and users can precisely query the data stored in these fields.
Consider the user experience of providing the data, such as how a constituent can provide information through a form, to help decide on the type of field to use. For example, class year can be stored either as a free-text field or as a field using a prompt list. On a giving form, if a constituent is prompted to provide a class year, consider if you want that constituent to type the year (1997, 1978, 2001, etc.) into a free-text field or if you want the constituent to select a year from a prompt list of years. Evaluating the best experience for the constituent could determine how a field should be configured in the database.
Custom Field Settings
The following settings are available for configuring a field:
Details
Setting | Description |
---|---|
Status | Set the status to 'Active' for currently used Fields. Inactivate fields that are no longer used without fear of losing data associated with them. |
Scope Category | The available scopes will dynamically show based on the category selected. Records: The Records category includes primary records in the database, like constituent and dataset records. Related: The Related category includes objects that have to be associated with a primary record, such as gifts, addresses, jobs, etc. |
Scope | Scope describes the object to which the field is related. Do not change the scope of a field once data exists for the field. Changing the scope of a field will not update existing values, resulting in orphaned data. Also, existing filters and exports will continue referencing data with the original scope. If data should be scoped differently, create a new field with the desired scope. Then, export the existing data and import it to the new field using Upload Dataset. |
ID | This is the unique ID that Slate will use to identify specific fields in the database. Each field must have a different ID. It is best practice to have this ID be all lowercase with no spaces or special characters other than an underscore. Once this ID is set and in use, you should never change the ID. |
Name | Give the field a name. This name will be visible administratively only. It is acceptable to change the name, even if data already exists for the field. |
Folder | Adding fields to folders provides for better organization and filtering options. Select a folder or select Other and enter the name of a new folder. It is highly recommended to organize your content with folders. |
Category | Select an existing category or select Other and enter a new category for the field. Fields can be queried by using category. |
Field Type | Select one of the listed field types.
Depending on the type selected, additional configuration fields may appear. |
Prompt | Select from any prompt lists that are available within your database. Prompt lists are agnostic to scope. |
Ordered | This setting is available for fields that store multiple values. This setting is used for field values that are grouped together.
|
Appendable | This setting is available for fields that store multiple values. This will set the behavior for form submission or data imports for the field when a value for this field already exists for a record.
|
Unique for Merging | Use this setting with caution. When configured as Value containing a unique ID that identifies a single record for merging, Upload Dataset and Form/Event/Interview submissions will use this field's value to match records automatically. Consolidate Records will also use this field to find potential matching records. Fields should only be configured as unique if each record is guaranteed to have a unique value for this field. Examples of unique fields include:
|
[Advancement Only] Giving Tabs Insert | When the scope of Gift is selected, the Giving Tabs Insert setting will appear. The Gift scope covers Gifts, Pledged, and Planned gifts. When no tab is selected, the field will appear for all giving tabs. Selecting specific tabs will display the field only for those chosen giving tabs. |
[Advancement Only] Giving Tabs | When the scope of Gift is selected, the Giving Tabs setting will appear. This setting will display any giving tabs selected in the Giving Tabs Insert setting. |
Additional Settings
Beyond the fundamental settings listed above (configured on the Edit Field > Details tab), there are additional settings that can be configured on a field. These settings typically do not need to be changed.
Advanced Settings tab
Setting | Description |
---|---|
Unsafe |
Application-scoped fields are always considered Unsafe. |
Data Type | This setting provides the ability to specify if the field will contain free text or will conform to specific types of values. Filters will become available in the Slate Template Library for text-based fields based on the Data Type selected. Numeric types (Real, Int), as well as Date and Date/Time types, will be available as filters with comparison operators (<, <=, =, >=, >). |
XML Configuration Data | This is a legacy setting previously used to drive conditional logic on legacy XSLT application pages. This can now be handled on each form in a less technical format via forms. |
Display tab
Instead of the display settings below, Use custom tabs to display custom fields as necessary in records.
Setting | Description |
---|---|
Read Permission | This optional setting restricts the ability to view particular fields on a tab by setting a custom read permission. If the setting is blank, anyone who can view the field's tab on the record can see the value of this field. |
Write Permission | This optional setting restricts the ability to edit particular fields on a tab by setting a custom write permission. If the setting is blank, anyone who can view the field's tab on the record can update the field value. |
Notes tab
Notes are internal-only for each field. These notes might include the field's purpose, its importance to your institution, and so forth.
Snapshots Tab
Once a field has been created, a new tab will appear. The Snapshots tab will display all updates to a field. Each timestamped update can be clicked to see the previous field settings.
Creating a Custom Field
To create a new field, open the Fields tool in the database, and select New Field.
Note the paragraph at the top of the Fields page, providing a list of field IDs reserved for standard Slate fields. Do not create a field that uses any of the following IDs:
resident
phone
business
mobile
email
birthdate
ssn
ref
name
first
last
middle
preferred
prefix
suffix
sex
resident
In the Fields tool, make sure to select or provide the appropriate values for scope, provide an ID, name, and so on. Once the field is configured as desired, click Save.
Note: Fields can only be deleted through a Retention Policy.
Form and import destinations are cached to improve performance. The cached values are refreshed approximately every 5 minutes in production. You can force-refresh the cache by clicking the link at the top of the Fields page.
The database will generate exports and filters during the overnight process for any newly created or updated field. To run this process on demand, click Database on the Slate navigation bar and select Refresh Configurable Joins Library in the Queries section.