Creating a Custom Application Page Using Form Widgets

📚 Part of the series Application Building Phase II: The Slate-hosted Application

What Is a Form Widget in the Slate-Hosted Application?

In the Slate-Hosted Application, specific scoped information can be collected in a one-to-many relationship (for example, multiple schools, jobs, or activities for a single applicant) through popups known as form widgets. A form widget is a form created in the Forms Tool with a specific widget scope applied. The form is then embedded into application pages that the applicant navigates to when filling out the application.

How Form Widgets Work

Form widgets are displayed to applicants as popups that open when they click a button like Add or Add Institution. Each time the popup is completed and saved, a new row/entry is created and displayed on the form widget within the application page.

Common Example: School  Widget

A familiar example of a form widget is used on the School History page of the application:

• The applicant clicks Add Institution

• A popup appears asking for details like school name, CEEB code, address, and level of study

• This popup is a form widget built with the School Widget scope

• The widget is embedded on the School History page using the Widget Table option in the form’s palette

Each institution the applicant adds is stored as a separate record on the school table tied to the same application.

Application pages that use form widgets

If you’re in a database provisioned from one of our admissions models, you may find a folder in Forms called Slate-Hosted Application Pages.

Some of the forms in this folder represent entire application pages, while others represent the widgets embedded in those pages. These include:

• Activities/Interests

• Courses

• Employment History

• Recommendations

• Relationships

• School Reports

• School History

• Sports

If you don’t see these forms, you can import them using the Suitcase IDs found in the application-page articles in this section.

When to use application form widgets

Some things to consider when deciding whether you want to create or modify form widgets on your application:

• Application form widgets are designed for use only with Slate-Hosted Application–scoped form pages. These widgets are not intended for use outside of the Slate-Hosted Application, including on forms like Application scope, Person scope, or Application Creation scoped forms.

• Standard and custom fields can be labeled and ordered as desired, and can appear conditionally.

• An applicant can add up to 99 responses in an application form widget. This is recommended if multiple submissions are expected.

• Use only one application form widget of each type per application. Widgets will display all records saved on the corresponding data table on the person record. For example, school record information entered in an application form widget to collect high schools attended also appears in a separate application form widget for colleges and universities attended. Instead, one widget should be used to collect all school data in the application.

• Required fields on custom application widgets. Unlike application-page scoped forms, fields on a custom widget on a custom application page can be configured as Required and will be enforced in the application.

Step 1: Creating the widget-scoped form

When you create a form, you must set a scope for the data collected on that form.

You may have noticed that, in the list of scopes, there is a group called Page Construction Widgets. Each of the scopes in this group correspond with a type of form widget.

Let’s go with the School Widget as an example. If you select this scope, the data registrants enter in the form fields you create can be mapped to system Schools fields.

We can repeat this for as many widgets as we need on a given application page.

Step 2: Creating a form to embed the widget

Next, we create a form of the scope Slate-hosted application page to embed the widgets, in this example called Education History.

On this form, we add a widget table from the form palette. From the Widget Form list, we select the widget form we’ve just created.

We repeat for as many widget-scoped forms as we created in the previous step but still following best practice of one type of form widget per application.

Step 3: Collecting data from the widgets

The fields on our application form widgets can be mapped to data on the appropriate tables on the Profile tab of the person record—in this example, Schools.

Step 4: Viewing data on the form widgets within the application

To display data entered on an application page, you must configure Custom List Fields. Custom List Fields control which data points are shown to the applicant after they save an entry from a form widget pop-up by allowing you to add exports and filters. To configure, navigate to the form widget and click on Edit Properties. Within this section you will see the area to set up the Custom List Fields from the General tab.

Viewing form widget data in the Reader

Form widgets do not have form responses and the data only maps to system fields for saving. This means that you can query on the information but for Auto PDFs, such as those in the Reader, the entered data will not render. Instead use a Data Container, Custom PDF, or a Reader portal to display a form widget’s custom fields in the Reader.