Forms Overview

Forms collect structured information and save it in your Slate database. A form can create a new record, update an existing record, store a submitted response, trigger a communication, or support another Slate process, like an event, interview, or workflow.

Forms are interfaces for adding and updating data across Slate, including:

• The person record (for example, creating a new person record from an inquiry form)

• Event and interview registrations

• The tabs on person or dataset records

• Portals, dashboards, and workflows

What do you want to collect?

Forms are flexible and can collect data in a wide ranges of contexts, including (but in no way limited to):

Creating a form

To make a basic form:

1. Go to Forms

2. Select New Form.

3. Configure the following settings:

   • Status: You can leave forms in the Tentative status while you’re configuring them. Set the status of public forms to Confirmed/Active when you’re ready for respondents to open the form from its public URL.

   • Folder: Folders help staff keep forms organized in the Forms list. The user setting identifies the owner or primary Slate user for the form and can be used for filtering and merge fields.

   • Title: Enter a public-facing title to appear at the top of the form.

4. Select Save. You arrive at the form summary page.
   

You’ll find the following on the form summary page:

• Edit: Edit form settings (the same you configured when you created the form).

• Edit Communications: Create transactional form communications

• Edit Form: Edit the form content

• Export Data: Generate a quick query of the form response data and export it in the format of your choice.

• Export PDF: Generates a PDF of form registrations.

• New Query: Create a new query based on the form response data.

• New Report: Create a report that incorporates the form response data.

• URL / Edit URL: Access the public-facing form via the URL. Replace the form’s default URL, which is a globally unique identifier, with a human-readable URL of your choosing.

• Edit Documents: Add or edit documents.

• Registrants: Review submitted registrations. Select one of the tabs to see only registered guests, cancellations, or all registrants.

• New Registration: Create a new form registration manually, for example when registering on behalf of someone else.

📖 For more detail, see Creating a Form

Form properties

Select Edit Form. You’re brought to the form build page. Here you can drag form fields from the palette and place them in the order you want them to appear on the form. But before we do that, select Edit Properties. These properties define the form's record context, access behavior, layout, and related settings. Configure these properties before adding complex field mappings or conditional logic, because the form scope determines which fields and features are available.

📖 Form Settings - Edit Properties

Scope

Scope determines the type of record or object associated with the form response. Common scopes include:

• Person: Collects or updates information on a person record. Inquiry, advising, and gift forms are commonly person-scoped.

• Reader: Presents a review form in Reader.

• Dataset: Creates or updates records in a dataset, such as organization contacts or alumni volunteers.

Security

Form settings control who can open a form, whether a response can create a new record, whether the same registrant can submit more than once, and whether a form stops accepting submissions after a deadline or registration limit.

Use deadline and time zone settings together when a form should close at a specific date and time. Use registration limits when the form should stop accepting responses after a certain number of submissions.

📖 Access and submission conditions

Custom list fields

You can add exports that replace the default Registrants columns. For events and interviews, these custom registration columns carry over into the Launch Check In page.

Merge fields

Add personalized content to the instructional text or display labels in your form by adding merge fields.

Form palette and mappings

The form palette contains the fields, content blocks, and widgets that can be added to a form. Choose each palette item based on what the respondent should do and how Slate should save the response.

Use field types that match the type of answer being collected:

• Text box or paragraph text fields collect free-text answers

• Select lists or option buttons let the respondent choose one value from a list

• Checkboxes or multi-select lists when the respondent can choose more than one value

• Date, birthdate, street address, location, material uploader, payment, signature, and others collect dedicated inputs

• Headings, header rows, instructions, and section breaks help to organize long forms

📖 Form Palette

System field mappings

A field mapping tells Slate where to save a submitted value.

When you select a form field and view its settings, you’ll find System Field as one of the configurations. It provides a user-friendly way to choose the destination category and field. After a destination is selected, Slate stores the field destination in the export key.

The available mappings depend on the selected field type and the form scope. For example, a text box can map to text-based fields, while a select list can map to fields that use prompt values.

📖 Form Settings - Field Configurations

Prompts and answer options

Prompt-driven fields present predefined answer options. When a field is mapped to a system field that uses prompts, Slate can populate the prompt list from the mapped destination. Keep system prompts connected unless the form requires a deliberate display change.

Prompt lists help keep submitted data consistent. They also make later querying, reporting, communication targeting, and automation easier.

Required fields

Required fields prevent a public respondent from submitting the form until a value is entered. Require only the fields that are essential for the process.

For public inquiry forms, first name, last name, email address, and birthdate are especially important because they support matching and record creation. Avoid requiring fields that do not apply to everyone, such as middle name.

📖 Default Information / Required Fields

Conditional logic and dynamic content

Conditional logic and dynamic content keep forms shorter, more relevant, and easier to complete. Rather than showing every possible field to every respondent, you can show the right questions, prompts, instructions, or calculated values for the respondent's context or provided responses.

Conditional sections and fields

Use conditional logic when a field or section should appear only for certain respondents. For example, an event form can show payment options only when a paid selection applies.

Section breaks are useful when an entire group of fields should appear conditionally. Place the relevant fields between section breaks and apply the logic to the section rather than repeating the same logic on each field.

📖 Form Conditional Logic

Dynamic values and calculated fields

Some forms need values that are calculated from other fields, populated from known data, or passed into the form through a URL. Calculated fields can update values while the respondent completes the form. Query string parameters can prefill fields when the link includes known values.

📖 Calculated Fields in Forms

📖 Prepopulating or Prefilling Forms Using Query String Parameters

Merge fields on forms

Merge fields can personalize form labels and instructional text when the form has access to the relevant data. This is most useful when a form is opened through a secure link, a portal, or another context where Slate can identify the record.

Always test dynamic form content with records that match the intended audience. Public links that do not identify a person record cannot use record-specific data in the same way as authenticated or record-aware links.

📖 Merge Fields on Forms

Form communications

Form communications define what happens after a form is submitted. A form communication can send an email, display a confirmation page, or use the same message content for both.

📖 Form Communications

Triggers and groups

The trigger defines when the communication sends or appears. The most common trigger is Upon Registration or Update.

The group defines the communication channel and entry path. For example, a communication can apply to direct entry, administrative entry, email only, confirmation page only, or both email and confirmation page content.

Use separate email and confirmation page communications when the email should include branded email content but the confirmation page should rely on the public form page branding.

📖 Form Communications Triggers and Groups

Merge fields in communications

Form communication merge fields can reference the form, the submitter, the form user, or the submitted data. For most messages sent to a respondent, use merge fields that reference the submitted person or field values, such as the respondent's first name or email address.

📝 Note

Be careful with form-prefixed merge fields: these usually refer to the form submission or administrative context, not necessarily the person who completed the form. Use the sys-prefixed merge fields in form communications instead.

Testing communications

Test form communications before sharing the form link publicly. Use a test record or the form communication testing tools to confirm that the message sends, the confirmation page appears, and merge fields populate as expected.

Collecting registrations

When you set a form’s status to Confirmed/Active, you can share its URL on your website, in mailings, in portals, or through other public channels. Public-facing forms use your Slate-hosted institutional branding.

Registrations

Submitted responses appear on the form summary page and on the associated record’s timeline. If a form field is mapped to a standard or custom field, the submitted value can update the mapped destination. The submitted form response also remains available as a form registration, so staff can review what the respondent submitted.

Updating existing records

When someone submits a person-scoped form, Slate evaluates whether the submitted information matches an existing person record. Slate first checks for an exact match on first name, last name, and email address. If that does not match an existing record, Slate checks first name, last name, and birthdate.

If either combination matches exactly, Slate attaches the form response to the existing person record. If neither combination matches, Slate creates a new person record and attaches the form response to that record.

Slate has similar, but not identical behavior when it attempts to match records of other scopes, like dataset records.

📖 Matching criteria

Next up

Start with a simple form, then test the full path from registration to record update to delivery of a form communication.

➡️ Creating a form