1. Home
  2. SchoolForms Online (SFO)
  3. Enrollee and Family Forms Explained

Enrollee and Family Forms Explained

Before electronic forms, parents would have to fill out stacks of paper forms on which they had to write the same information over and over again (name, address, grade, etc.). Online forms are different. Best practices in building online forms is to ask for data only once.

As you plan your forms, you will make decisions about the best way to ask for the information you need, and be clear about where the data will be stored in your solution.

To whom will this form be Assigned: Enrollee or Families?

Forms are assigned either to the Enrollee (student) or the Families (both, if two families exist for a child). Ask: Is this data child-specific? Or does it pertain to the family no matter how many children are enrolled?

Assign to: Enrollee

Enrollees are students, and these forms are student-specific. Enrollee forms can display/collect both student and family data. An Enrollee form is assigned to only one family:

  • Enrollees: Family1, or
  • Enrollees: Family2

Most forms will pertain to only Family1, the custodial family.

Examples of forms that may be assigned to Enrollees for one family only are: Contract and Deposit forms, Permission forms, Health forms, Afternoon Activity Selection forms.

Assign to: Families

Forms that display/collect only family data (no student data at all) can be assigned to:

  • Families (published to both Family1 and Family2 if two families exist)

Family forms collect data that is specific to parents, no matter how many children they have enrolled at the school. Family forms use fields that are in the Families table; these are not specific to Family1 or Family2.

When you process the family form, SFO moves the data into the correct family file based upon the Family ID associated with the account that has submitted the form.

NOTE: Family1 and Family2 cannot see each other’s data in a Families form.

Examples of forms that are assigned to Families are those that collect family information that is not student-specific, such as: Parent Employment, Emergency Contacts, Auto License Plates for Parking, Parent Volunteer Choices, Family Physicians and Dentists.

Here are some important factors to understand when building forms to be assigned to Families:

  • A Families form will be posted for both families (if there is a Family2). When the form is submitted, the data will flow into the appropriate family record based upon the Family ID of the account through which the form was submitted.

Mapping Family Fields

If you use one field on a form for Family1 and the same field on a form for Family2, and this field is mapped only once to a field in PORTAL, the field will be populated by the first form processed—and then overwritten when the second form is processed.

CAUTION: If you duplicate a Family1 form and repurpose it for Family2, make certain you point the fields on the Family2 form to Family2 fields.

To avoid overwriting data, add the field to the field map multiple times, with a different destination field each time. For example, Pa_email may be mapped to the Families table, the Family1 table, and the Family2 table. Then, when building your form, make sure you select the Pa_email field that is mapped to the appropriate destination.

Building Forms to be Shared by Family1 and Family2

There are some circumstances in which schools want a form to be shared by both families, such as having both families sign off on the same enrollment contract when custody is shared, or stipulate permissions. These circumstances can be fraught with complexities, and each school must make form design decisions based upon their own business rules. Whether using paper forms, or electronic ones, the families we serve will inevitably challenge us!

We can recommend some best practices:

REMINDER: When a form is submitted, it is automatically captured at that moment in time as an uneditable PDF. These PDFs are stored in iRDocuments.

If you want both families to sign an enrollment contract, you could:

  • Issue two contracts: Build a Family1 contract with an F1_signature field and a Family2 contract with an F2_signature field. When those contracts are submitted, you will have a PDF of each stored in  iRDocuments.
  • To have one contract that is counter-signed, first signed by Family1 and then signed by Family2, you will still need to build two forms, but you will publish the contract in two phases: first post a contract to Family1 with an F1_signature field. When F1 has submitted the contract and the form has been processed, publish the Family2 version of the contract—in which the F1_signature displays as read-only and the F2_signature field is to be signed.
  • There is no need to map signatures, as they will not be displayed on a layout in FileMaker.

If you want both families to sign your general permissions form (such as a form for boarding students’ off-campus permissions, for example), you could:

  • Issue the form in two phases, as above, or
  • Map the permissions for both families into separate F1, F2 permissions fields and then set up a calculation to create a final permissions override. That is, if both F1 and F2 agree, use that permission; if one says Yes and one says No, then No will prevail.
Need Support?
Can’t find the answer you’re looking for? Don’t worry we’re here to help!
Create a Ticket