Skip to main content
Skip table of contents

Best Practices

An online form is a digital version of a document that is accessible in a web browser. The online form is made up of one or more pages that contain content and data elements. You have control over which elements your form displays, where they appear on the form, and how they behave for users. For instructions on how to use elements, refer to Form Builder- Elements.

Field Naming Conventions

Use field names that start with a common prefix and include terms that describe the core purpose of the data to be collected and stored within the fields. Capitalize each term after the prefix within the field name for ease of reading.

Field names can only contain letters, numbers, and underscores. They must begin with a letter or number; They cannot begin with an underscore.

The following list contains examples:

  • stu_FirstName for student's first name
  • stu_DoB for student's date of birth
  • stu_BirthCountry for student's birth country
  • stu_HomePhone for the student's home phone number
  • p1_FirstName or c1_FirstName for the first parent's or contact's first name
  • p2_FirstName or c2_FirstName for the second parent's or contact's first name
  • e1_FirstName for the first emergency contact's first name
  • sib1_FirstName for the first sibling's first name

These field names are used throughout the process and as part of data delivery into the SIS. Therefore, updates to existing field names are not recommended.

Using Groups and Sections

Group and Section elements are important structural and hierarchical elements within forms. All fields on the form must be contained within a Group, all Groups on the form must be contained within a Section, and all Sections on the form are by default contained within a Page. These elements are not only a necessary part of form construction but also provide efficient ways of organizing content on a form.

Heading and Paragraph elements do not adhere to the same structural and hierarchical restrictions as fields - they can both be placed outside of a Group or Section.

How to Determine What is Contained within a Group or Section

The elements that appear below a Group (e.g., Group 1a) and above the next Group (e.g., Group 1b) or Section (e.g., Section 2) are contained within that Group (Group 1a). The elements that appear below a Section (e.g., Section 1) and above the next Section (e.g., Section 2) are contained within that Section (Section 1).

See the following example of elements within a form page:

  • Heading: Family Information
  • Section (Section 1)
  • Heading: Parents/Guardians
  • Paragraph: Please fill out the below information regarding the student's parents/guardians.
  • Group (Group 1a)
  • Heading: Parent/Guardian 1
  • Field: p1_FirstName
  • Field: p1_LastName
  • Group (Group 1b)
  • Heading: Parent/Guardian 2
  • Field: p2_FirstName
  • Field: p2_LastName
  • Section (Section 2)
  • Heading: Siblings
  • Group (Group 2a)
  • Field: stu_Siblings

In the above example, the "Parent/Guardian 1" Heading through the "p1_LastName" fields are contained with Group 1a. The "Parent/Guardian 2" Heading through the "p2_LastName" fields are contained within Group 1b. The "Parents/Guardians" Heading through the "p2_LastName" fields are contained within Section 1, including Group 1a and Group 1b. The "Family Information" Heading is not contained within any Group or Section.

How to Use Groups and Sections to Control Heading Level

The structural/hierarchical element that contains the Heading will dictate the level of the heading:

  • If a Heading is contained within only a Page, it will be an h1 (40px).
  • If a Heading is contained within a Section but not a Group, it will be an h2 (32px).
  • If a Heading is contained within a Group, it will be an h3 (26px).

How to Use Groups and Sections to Efficiently Organize Content

Place all conceptually similar elements in the same Group or Section. If a grouping of elements needs to be shown or hidden conditionally, you can add Show If rules to the Group or Section to affect all of the elements contained within it, without needing to define those Show If rules individually on each element.

See the following example of elements within a form page:

  • Section (Section 1)
  • Heading: Middle School Agreements
  • Group (Group 1a)
  • Heading: Bullying Policy
  • Field: stu_BullyingPolicyAgree
  • Group (Group 1b)
  • Heading: Field Trip Permission
  • Field: stu_FieldTripPermissionAgree

In the above example, if the middle school agreements should be shown to all students in grades 6-8 but the field trip permission should only be shown to students in grade 8, you would add Show If rules to Section 1 for grade equaling either 6, 7, or 8, and then you would add Show If rules to Group 1b for grade equaling 8.

Show If rules cannot be placed directly on a Heading or Paragraph. Thus, if a Heading or Paragraph needs to be shown or hidden conditionally, place it within its own Group or Section and add the Show If rules to the Group or Section.

Checkbox vs Dropdown vs Radio

Although Checkbox, Dropdown, and Radio elements can be used to collect similar data, there are different situations in which each element works best. Take the following information into consideration when deciding which element type to use:

Element Type

Considerations

Checkbox

  • Easiest for families to select or deselect
  • Ideal for agreements
  • Ideal for Yes-only scenarios
  • Ideal for Show If rules triggers (e.g., "Mailing address is different from physical address")

Dropdown

  • Can either have an initial "Select" value or can default to preselecting the top-most list option
  • Ideal for lists with many options (e.g., State, Country)
  • Should be used for optional fields with multiple response options
  • Should be used for Read-Only fields pre-populated from a list/code-based field in the SIS
  • Must be used when needing to display options conditionally based on other values entered into the form

Radio

  • Once an option has been selected, the parent is unable to deselect all options
  • Ideal for Yes/No scenarios
  • Ideal for lists with few options (e.g., Gender)
  • Ideal for lists with lengthy values as options
  • Should not be used for optional fields

Defining List Options

Each list option has three values: a Display value, a Stored value, and an Integration value. Keep in mind the purpose of each value when defining list options.

  • Display values appear to parents on the form; make sure they are user-friendly, that their length is mobile-friendly, and that they do not include any unknown codes or acronyms.
  • Stored values are what is actually stored and displayed within records (like Roster and Submission records), what is referenced within Show If and Required If logic, and what is referenced in other tools like filters. These are generally shorter or more succinct than the Display values to make logic creation easier, but make sure that they are still easily readable and understandable by your administrative users.
  • Integration values are referenced when importing data from a SIS and what are used when delivering data to a SIS. Make sure to use the appropriate value or code that your SIS stores for the relevant field.

The following list contains examples:

  • Display: Yes, No
  • Stored: Y, N
  • Integration: 1, 0

Predefined Lists vs Inline Lists

When creating a Dropdown or Hidden Dropdown element, you are presented with the option to use a Predefined List or to define a list inline within the element itself. Both options have their merits and it is important to think about the purpose of the list and the frequency with which you intend to use it. Take the following information into consideration when deciding which list type to use:

List Type

Considerations

Predefined List

  • Defined outside of an individual form, and can be referenced by multiple fields within a single form or across multiple forms
  • Allows you to make changes to the list once and have those changes propagated everywhere the list is referenced
  • Ideal for lists that will be used elsewhere in the form
  • Ideal for lists that will be used in other forms for the same academic year
  • Must be used when needing to display options conditionally based on other values entered into the form

Inline List

  • Defined inline within an individual field within a form, and cannot be referenced by other fields
  • Allows you to make changes to the list without affecting any other fields or forms
  • Ideal for lists that will be used just once within the form
  • Ideal for lists that will be updated yearly
  • Must be used with Radio button fields

Whichever list type you use, remember that editing a list option may have downstream effects. This can cause issues with current or past years' forms and with submitted data. Additionally, workspace tools can be affected. For example, if a list option is referenced elsewhere in a rule/filter, the rule will also need to be updated.

Existing Predefined Lists are likely to be in use by other forms from the current year or past years. It is strongly recommended not to delete any of these lists or items within these lists. Deleting an existing Predefined List will remove that option on any form the list is associated with and as an option for students whose forms have already been submitted. This could possibly corrupt student data when submitted. Instead of deleting or editing existing Predefined Lists, duplicate the existing Predefined List and make any needed edits to this new list.

Restricted and Locked Elements

Forms can be configured by Enrollment Support to restrict what a user can edit on a form on an element-by-element basis. The purpose of a restricted form is to allow access to the Form Builder to update the form but reduce the risk that these updates have an adverse impact on critical form fields. A form can be further restricted by locking individual elements. When an element is locked, you are unable to delete the element or edit any functional behavior of the element (Field Name, Read-Only, list option Stored Values and Integration Values, Requirements, Visibility, etc.). However, you can edit textual display attributes of the element (Label, Note, Help Text, translations, etc.) and reposition the element on a page. After a form has launched for parent use and PowerSchool Enrollment Support locks elements within a form, the Form Builder can be made accessible to administrative users with the Configuration role to make minor changes to the form and manage the form's print templates.

Adding Rules to Elements

When adding rules to elements:

  • Use Required If rules to require fields only in the specified conditions. When Required If rules are used, the field will only be required for those students that meet that condition.
  • Use Show If rules to show elements (fields, groups, sections, pages) only in the specified conditions. When Show If rules are used, the element will be shown to those students that meet that condition.
    • Use the "is" evaluator within rules to specify the exact value that must be in place in order for the rule or logic to take effect. This is typically used if an element, group, section, or page is only applicable to a subset of families or students.
    • Use the "is not" evaluator within rules to specify the exact value that must not be in place in order for the rule or logic to take effect. This is typically used if an element, group, section, or page is applicable to all but a subset of families or students.
    • Use Show If rules to ensure the right families respond to a question/field without needing to create multiple fields to capture the same information from different subsets of students. For example, if students in grades 6-8 at School A need to agree to the internet policy but only students in grade 8 at School B need to agree to the internet policy, you can use the same field to collect this information from both of these subsets of students with the right Show If rules. This simplifies everything downstream because you'll always have only one field to look to for this information.
    • Groups, sections, and pages can be used with Show If rules to control the visibility of all of the elements within them. This functions hierarchically. If a group is being shown or hidden through Show If rules, this will also show or hide all content and fields within that group. If a section is being shown or hidden through Show If rules, this will also show or hide all content and groups within that section, and all content and fields within those groups. If a page is being shown or hidden through Show If rules, this will also show or hide all content and sections within that page, all content and groups within those sections, and all content and fields within those groups. If one of these structural elements (groups, sections, pages) is being shown through Show If rules, it's possible for some elements within it to still be hidden if those sub-elements have their own Show If rules defined.
    • Use Show If rules on a field, its group, its section, or its page while also setting the field to Required to make it required whenever it is shown.
    • When using Required If rules on a field within a group, section, or page that has Show If rules implemented, it is important to keep those Show If rules in mind. A field within a group, section, or page with Show If rules should only be required in a condition that also satisfies the Show If condition. If a family cannot see a field that is required, they will not be able to submit the form properly. For this reason, it is important to thoroughly test all rules in the form Preview as you add them to elements on the form. The more complex the rule, the more testing that needs to be done.


JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.