Below are some frequent topics related to using the Form Builder module in Slate.
Do you want to save and store this data on the student record? If yes, map it to a system field.
You might consider using unmapped form fields for things like "Will you be joining us for lunch?" on an event form. This is an example of data that you're interested in collecting that can be stored with the specific form rather than in the student record.
Did you overwrite the system prompts and modify your list? If so, make sure you do not have any 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 storing within Slate; you just could not see it on the form.
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!).
- You might think that 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.
- Great question, and we're glad you asked! 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 are assigning 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 that is submitted administratively.
- Hidden fields are fields that will exist, but be 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, if you have a specific inquiry form for Engineering majors, 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.
For example, 148715dc-918e-48b3-b2eb-a1bd00f357ff. Look familiar? The GUID, or Globally Unique Identifier, is what we use in Slate to make sure we don't have duplicate values popping up all over the place. You should not ever modify a guid as it is used to associate your fields and values back to the system.
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."
- While your field may be formatted correctly now, in order for the value to display appropriately, you will have to update the field on the record. You have a few options here:
- 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.
- Use an export/import process to update all of the 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, matching on ID, and updating 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.
If the form never loads, you can assume that 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.
If a form has been created, but not yet saved, the conditional logic options will not display. Quick fix: resave the form properties.
Slate is not designed to copy the logic that you create within a form, so you will have to recreate this when you copy the form.
If you find yourself having entire sections of the form that should display conditionally based on the selection in a certain question, 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.
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 be enable Slate to query the user's record.
- The "Edit Conditions" interface is split into two sections. The topmost section controls the Access Conditions, and is only be available if the respondent will be known prior to 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. I.E. No Application scoped filters in a Person scoped form.
- Application and Person scoped filters used in Submission Conditions are evaluated inclusive of the data on the form. Stated plainly, if data entered via the form will update a system field in such a way that the filter criteria is met, then 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. I.E. The message is shown when the registrant does NOT meet the filter criteria. (This maybe be a little disorientating to being with, hence the emphasis.)
Quick fix: You can put a space in 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.
- 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.
- 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 existing 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.
- 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 sort of 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.
Do you have section breaks in between the schools? If not, Slate is recognizing the schools as the same and will automatically fill both out. Adding in a section break allows you to define the schools as separate institutions.
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 and can be changed by modifying the properties within 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 login and a selection of an application round where the student has started an application. A good example of an application-scoped form would be a Decision Reply Form where the student decides if they are going to 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. In order 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 into 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 within 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. If you are attempting to add your Reader Review Form to the Reader and you do not see it as an option in the dropdown, the scope is likely incorrect.
- Dataset: Dataset-scoped forms, for form and event registrations, are intended only for a particular dataset (e.g., organization contacts, organizations, alumni 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. Schools will often use these to provide comments on things like college fairs, high school visits, etc.