Below are some frequent topics related to using the Form Builder module in Slate.

Forms

Should I use mapped or unmapped fields?

Do you want to save and store this data on the student record? If yes, map it to a system field.

On an event form, you might consider using unmapped form fields for things like "Will you be joining us for lunch?". This is an example of data that you're interested in collecting that can be stored with a specific form rather than in the student record.

Are prompt values not saving on your form?

Did you overwrite the system prompts and modify your list? If so, ensure you do not have extra spaces after the prompt values. This prevents the values from saving in the form. Don't worry; you haven't lost this data—it was still stored in Slate; you could not see it on the form.

I can't add my custom field to my form.

If you've just created your new field, you may need to refresh the fields cache before adding it to your form. Cached values are refreshed approximately every 5 minutes in production—once refreshed, any new fields and prompts will be made available for use throughout forms and queries. If the field is needed instantly, force-refresh the cache by navigating to Database > Fields and clicking on the force-refresh hyperlink. You'll see a message that reads "OK," acknowledging that the field is now available. If your field uses new prompts, you must repeat the process in Database > Prompts.

If refreshing the cache doesn't fix the issue, you may need to select a different content type from the Form Builder Palette for your field type. For example, if your field uses a prompt list, it won't be selectable with a Text Box content type; you'll need to use a prompts-compatible content type like Check Boxes, Selectable, Option Buttons, Rating Scale, Select List, or Multi-select List instead.  

I don't see my field as an option in my form communication.

Is your field unmapped? Did you assign it an export key? When you have an unmapped form field, you will not see the field as a merge option unless you have added the key (lowercase, no spaces!).

How do I capture Parent Email on my inquiry form?

• You might think you can tie the parent email back to the system field for "Relationship: Parent Email," but you should not do that. A best Slate practice is to leave this as an unmapped form field on your inquiry form. This still allows you to query on the existence of the field and use it as a merge field for mailings.

• In order to have the parent email mapped correctly on the student record on the relationships tab, Slate needs more information (e.g., the Relationship Type, Parent First name, Parent Last name, etc.). This is typically information that you aren't collecting (or don't want to collect) on your inquiry form. Best practice: map this data to the Relationship record at the point of the application submission.

Field Properties—Should I use Internal Only or Hidden?

• Internal Only fields should be used if you are going to enter information administratively that you don't want the student to see. For example, if you assign a particular student employee to a campus visit, you would create this as an internal-only field. Important note: internal-only fields exist only on a form response submitted administratively.

• Hidden fields will exist but are hidden on both a public and administrative form response. They can be used to default to particular values or, be used in a calculation. For example, suppose you have a specific inquiry form for Engineering majors. In that case, you could create a hidden field that flags this student as an engineering major without the student ever selecting the option (or knowing it was there).

• Internal-only fields only exist on versions of the form that are submitted administratively. Hidden fields exist on both administrative and public versions of the form.

Why does everyone keep saying GUID, and what is a GUID?

For example, 148715dc-918e-48b3-b2eb-a1bd00f357ff. Look familiar? The GUID, or Globally Unique Identifier, is what we use in Slate to ensure we don't have duplicate values popping up all over the place. You should never modify a GUID, as it associates your fields and values back to the system.

Is a Form Value Displaying as a GUID?

Check the formatting of the field itself. In a majority of these cases, you've set the "Value" of the field to "Store Value" rather than to "Store Prompt ID."

Is a Form Value Still Displaying as a GUID after Fixing the Field?

• While your field may be formatted correctly now, for the value to display appropriately, you will have to update the field on the record. You have a few options here:

  1. Update the records as you view them. It’s as simple as clicking “Edit” and “Save” on the tab where the field is displaying—there is no need to modify any values at all, but ensure that the value displays correctly after saving.

  2. Use an export/import process to update all fields in a batch. Export the values from the form response for your population that needs to be updated, along with a unique identifier (such as Slate ID). Then, you can import these values back into Slate, match them on ID, and update the field in question with the new values. If you're updating an application-scoped field, take care to ensure you are using an app-scoped unique ID, so you are updating the appropriate application. This process can be a little nuanced; don't hesitate to submit a service request if you have any questions.

Conditional Logic & Form Conditions

Our form is live, but it just says "Loading..."

If the form never loads, you can assume there is an issue with your conditional logic. Troubleshoot this problem by checking out each field that has conditional logic on it within your form, to see if you can spot any errors in the logic. The errors will typically be displayed in red text.

Don't see the ability to add conditional logic to a field?

The conditional logic options will not display if a form has been created but not yet saved. Quick fix: resave the form properties.

Conditional logic doesn’t transfer when I copy the form.

Slate is not designed to copy the logic that you create in a form, so you will have to recreate this when you copy the form.

Have entire sections of your form that need conditional logic?

Suppose entire sections of the form should display conditionally based on the selection in a specific question. In that case, there's no need to apply logic to each individual field. Instead, group the fields together and place section breaks at the beginning and end. Then, apply the logic to the first section break only. You'll see that the entire section will now display (or not display) as intended.

I don't have the option to add Access Conditions to my form.

Go to Edit Conditions on your form and make sure your form is either Application-scoped or Person-Scoped and the require log-in box is checked. This will enable Slate to query the user's record.

What are form conditions?

• The "Edit Conditions" interface is split into two sections. The topmost section controls the Access Conditions, and is only available if the respondent is known before the form loading, for example, when the form is either Application scoped, or Person scoped and flagged for "Require Login" via the "Edit Properties" interface. The lower section controls the Submission Conditions and is available at all times.

• Merge fields are not currently supported within the messaging.

• The filters available for use are contextually aware of the form's scope. IE No Application scoped filters in a Person scoped form.

• Application and Person scoped filters used in Submission Conditions are evaluated, including the data on the form. Stated plainly, if data entered via the form will update a system field so that the filter criteria is met, then the submission will be permitted.

• For both access and submit conditions, the message is written for people that CANNOT access/submit the form, while the filters are written to define those that CAN. IE The message is shown when the registrant does NOT meet the filter criteria.

Formatting Tools

There is no space in between the columns I've created (and it looks awful).

Quick fix: You can put a space between your columns by inserting a blank instructions box with a defined width. For example, First Name width: 48, Instruction Box width: 4, Last name width: 48.

I can't view my fields when I use particular formatting options.

• Make sure that you are selecting formatting options that fit your field options! For example, if you have a prompt list tied to your field, you don't want to pull in a text box. Is your field multi-select? Make sure to grab the right dropdown (or checkboxes).

• Think about what you're trying to accomplish—maybe this presents an opportunity to rethink how you want to collect information in general.

Other Common Questions

Want to make changes to your form for your new cycle?

• Don't delete your old fields! Doing this will remove this data from any past submissions of this form. Instead, create a NEW form—you can copy your current form and then make changes to this new form for your new cycle.

• You can rename the form to indicate it is specific to a particular year or other archived information and set the status of this old form to "Inactive"—this will drop it to the bottom of the forms list.

Rule didn't fire when you resubmitted a form?

• Form Submission rules only fire one time upon form submission. This means that if a form is submitted again by/on behalf of a particular student, the rule will not fire again.

• If you are testing behavior or administratively entering information on a form and have a rule set up to trigger some action upon submission, you should cancel the initial form registration and also DELETE that form registration from the Cancellation section of the form. Once this is done, your rule will fire as intended.

We have multiple schools on our form; if you fill out one, the other automatically populate.

Do you have section breaks in between the schools? If not, Slate recognizes the schools as the same and will automatically fill both out. Adding a section break allows you to define the schools as separate institutions.

Why are there so many form scopes, and what does each mean?

Forms now have many available scopes. When creating your initial forms in Slate, they will mostly be person scoped. If, when attempting to access your form via the URL, you are presented with a login page, the form scope has been incorrectly set to Application. It can be changed by modifying the properties in the form itself. Background on the various options:

• Person: These forms should be used for things like your inquiry form, to collect or enter information on students while on the road, or for events that do not require a student to be an applicant. There are other use cases, but largely, this scope should be used to update anything related to the person record.

• Application: Application-scoped forms are forms that get filled out on a per application basis (you might want a form to be filled out for each application a student might submit rather than just one for the person themselves). These forms require a login and a selection of an application round where the student has started an application. An excellent example of an application-scoped form would be a Decision Reply Form, where the student decides if they will attend your school based on their application and your decision on that application.

• Application Creation: Similarly to the "Application" scope, Application Creation allows you to map to application field destinations. However, "Application Creation" does not require that the student be logged in—the form can be accessed publicly. This allows you to create an application for a person record upon form submission. For an application to be created, "Round" needs to be mapped, and "Submitted Flag" may also be mapped (this creates the application at a submitted status upon form submission). These fields can be set as "hidden" to ensure the same round is always created when a particular form is submitted.

• Person Page: This scope is used to create custom tabs to display person-scoped data points on the student record. After creating the form with this scope, add a field with the id "tab_Tab Name" and choose this form from the drop down list.

• Application Page: Application Page scope is used for forms that you wish to include in an application, or for a custom application-scoped tab that you would like to use to display fields on the student record. For example, if you would like to add a custom application page with questions that do not currently exist in the Slate Application template, you would use this scope.

• Reader: Reader-scoped forms should be used when creating forms that you wish to display within the reader. For example, your Reader Review form will be Reader scoped. The scope is likely incorrect if you are attempting to add your Reader Review Form to the Reader and do not see it as an option in the dropdown.

• Dataset: Dataset-scoped forms for form and event registrations are intended only for a particular dataset (e.g., organization contacts, organizations, alum volunteers, etc.). Note that forms and events scoped for a specific dataset will not add student records and should not be used to register students.

• Form/Event Notes: This option allows the user to create a form that can be tied to a specific form or event for internal use. Once created, these forms become selectable options on a form or event. Organizations often use these to comment on college fairs, high school visits, etc.