Slate gives you two powerful tools for recording custom data: custom datasets and entities. The right choice depends on whether the information should become its own record set or should remain repeated row data on an existing record.
Choose a custom dataset when staff need to search, secure, maintain, or report on the data as records. Choose an entity when the data belongs as rows on a person, application, or dataset record.
You might create a custom dataset for community-based organizations, alumni interviewers, or other recruiting partners when those organizations or people need their own records, fields, permissions, and reports. An entity is usually a better fit for repeated information on one applicant or application, such as scholarship awards, program interests, or interview assignments.
You might create a custom dataset for faculty, courses, residence halls, or other campus resources that should be maintained as records. An entity is usually a better fit for repeated information on one student record, such as class schedule entries, advising notes, scholarship records, or support-plan milestones.
You might create a custom dataset for funds, named spaces, companies and foundations, or other donor-related objects that need their own records. An entity is usually a better fit for repeated information on one donor or prospect record, such as ratings, committee memberships, research details, or stewardship milestones.
Using custom datasets
A custom dataset is a custom record type for records that are not already handled by a standard person, application, or organization-style dataset. Dataset records exist independently of other records and can store dataset-scoped fields, materials, addresses, devices, timeline activity, and custom tabs.
Custom datasets take more planning than entities. When you create one, you also build the baseline setup that makes it usable, including fields, matching criteria, Lookup behavior, the new record form, and display name rules when applicable.
Choose a custom dataset when:
The records should be searched, queried, reported on, or maintained as their own record set.
The records need dataset-scoped materials, user permissions, forms, event registrations, or accounts for secure forms and portals.
The records can exist independently of a specific person, application, or dataset record.
Many records need to reference the same object, such as applicants linked to one community organization, students linked to one course, or donors linked to one named space.
Dataset records can have one-to-one or one-to-many relationships with other records through parent/child relationships or related dataset row fields. A single related dataset row field value points to a selected record, but multiple records can point to the same dataset record, and related dataset row fields can be used on person, application, dataset, and entity scopes.
Using entities
An entity is a custom data table for grouped data points on a person, application, or dataset record. Entity rows store repeated entries, and entity-scoped fields define the columns for each row.
Entities work well when the data should appear as a table on the host record. You can display entity data on custom tabs with an entity widget, collect entity data on forms, and use entity data as merge fields or query exports.
Choose an entity when:
The data represents one-to-many rows on a host record, such as one applicant with multiple scholarship awards, one student with multiple schedule entries, or one donor with multiple prospect ratings.
Each row needs the same set of data points, such as entry name, effective date, status, or amount.
The row has meaning because of the person, application, or dataset record that contains it.
You need to collect or display repeated rows on a form or custom tab.
Entity data does not stand alone in the same way dataset records do. If the row should be searched, secured, managed, or reported on as an independent record, consider a custom dataset instead.
Choosing between a custom dataset and an entity
The decision depends on what the data represents, how you will maintain it, and where users need to work with it.
Requirement | Consider a custom dataset | Consider an entity |
|---|---|---|
The data should exist without a host record | The object should be its own record, such as a recruiting partner, course, faculty member, fund, or named space. | The data always belongs to a host record, such as an applicant, student, donor, application, or dataset record. |
The data is repeated rows on an existing record | Each row should become its own record or be reused by other records. | The rows describe the host record, such as applicant scholarships, student schedule entries, or donor ratings. |
Users need record-level features | The records need their own query base, dataset-scoped materials, user permissions, custom tabs, forms, event registrations, or accounts for secure forms and portals. | The table needs to appear on a host record and does not need a separate record-management experience. |
Many records should reference one shared object | Use related dataset row fields or parent/child relationships to connect applicants, students, or donors to the same dataset record. | Use a related dataset row field in the entity when an entity row should reference a shared dataset record. |
Historical data matters | Model history with records, fields, related records, or queries. | Use new entity rows for each historical entry when the history belongs to the host record. |
Automated maintenance matters | Custom datasets have documented dataset rule and import patterns. | Entity data can be collected through forms and imports. Verify the supported update path before choosing an entity for rule-driven maintenance. |
Setup time matters | Expect a larger setup project because baseline record features must be built. | Use an entity when the data belongs on an existing record and does not need standalone record features. |
When the choice is unclear
Start with this question: should this information be a record that staff search, secure, maintain, or report on beyond one applicant, student, or donor? If the answer is yes, use a custom dataset. If the information is a list that describes an existing record, use an entity.
If both options seem possible, choose the custom dataset only when the record-level capabilities fulfill a requirement. Otherwise, an entity usually keeps the data model smaller.