How Sections and Fields Work

Basic components of F180: Forms and Sections

Four types of forms:

  1. Profile - current information related to a faculty member, such as name, contact information, position titles, previous work experience, education, etc. 
  2. Activities - activities are reported by the faculty member per term/year.  There is one activity input form that governs what sections are shown to the faculty member 24/7/365.  Other activity input forms can be created based on a use case. (For example, an activity input form may be created so faculty can prepare for annual review.)  It is also possible to modify  per unit  what sections are shown to faculty. (e.g., the College of Fine Arts or the School of Medicine) or for use cases (e.g., input form that collects data for review cycles vs. input form that collects data for reporting purposes).
  3. Initiated Activity Input Period  - Based on a use case (example: preparing for annual review, regular term activity updates, updates to activities for accreditation, etc.) a software administrator can ‘initiate a period of activity input’.  A link is populated on the faculty member’s Action Items.  The link takes the faculty member to the Activity Input Form that is term/year specific and template specific.  There is also the option for faculty to ‘submit’ the form.  This action does two things 1) a snapshot is taken and stored for the faculty member of the state of that form when submitted, 2) an administrative report is updated so that software administrators can track faculty engagement during this input cycle.  
  4. Faculty Classification Input Form - A selection of faculty classifications that can be pushed as an Action Item.  Faculty can respond by providing the data requested and submitting the form.  The data is stored in the database when the submission occurs.

Build Basics:

  • Profile / Activity Forms contain sections.
    • Sections contain fields and activity classifications to collect additional metadata. 
      • Fields are used to collect specific data points for the intended purpose of the section.
        • Ex: In Membership, the fields could be Organization Name, Organization location, etc.
      • Activity Classifications can be used to collect additional metadata related to what is in the section. Activity Classifications can be used as filters in reporting and be added to a report as field data.
        • Ex: In Membership, the activity classifications could be Scope (Local, Regional, State, National)
Build Basics:
  • There are two types of sections: Default and Non-default.
    1. Default sections have limited configuration options.
      • Standard fields that cannot be added/modified/removed for this section. 
      • Activity Classifications can be added and different based on units.
      • Section Settings provide options and are editable for section behavior (cannot be changed based on where the section is section is used).
      • Sections that are default are easily distinguishable in the form and within the section.
Build Basics: Section Fields
  1. Non-default sections allow for more configuration.  
    • Fields can be added/modified/removed for the section.
    • Fields cannot be changed based on where the section is used.
    • Activity Classifications can be added and different based on units.
    • Section Settings provide options and are editable for section behavior (cannot be changed based on where the section is section is used).
    • Sections that are non-default can be distinguishable in the form and within the section
Build Basics: Non-default Section fields

Level 1 Forms (Hierarchy)

There is one form that exists at the highest level in the hierarchy that regulates the sections that are shown or not shown from the Profile and Activities links on the Menu.

Common between these forms:

  • These forms are managed by a level one administrator. 
  • Sections can be set to show on a form and sections can be set to not show on a form.  
  • This form will be the ‘repository’ of all sections created at Level 1.  The same is true for lower level unit forms and sections created at the lower level.  That form will be the repository for sections created at that unit and below.
  • Any section that is set to show on these forms is shown to faculty regardless of the faculty’s unit affiliation.  Meaning - a section at Level 1 (University) will be shown to faculty at a lower level (department).
  • A form will need to be created at the lower level unit to allow for modifications.
  • Modifications to the forms will not be visible (from the user experience) to the Level 1 administrator.  
  • The administrator will emulate a user at the unit level where the change was made in order to see the impact of the change.
  • A user has to be either primarily or secondarily assigned to the unit to have access to the form.

Differences:

  • There can only be one Profile form per unit, regardless of level, including Level 1. 
  • There can be multiple Activity Forms per unit. Only one regulates the sections shown to faculty when clicking on the Activities link on the Menu.  Other forms can be created for specific use cases (EX: annual review)  These additional forms are only shown to faculty using the Initiated Faculty Input feature (Administration > Administration > Initiate Faculty Input)

Modifying the Profile and Activities forms for lower units

Profile forms:

  • Parent / Child relationship
    • A child unit will inherit the parent unit Profile Form
    • There is no option to have different child forms
    • The sections on the inherited form cannot be set to Not Shown nor can the section be modified at the field level (no new fields can be added or fields removed). 
    • A lower level unit can make additional sections available to their faculty. 
      • Change “Not Shown” sections to be “Shown”. 
      • Add a new section that will only be available to the lower level unit.

Activity forms:

  • Parent / Child relationship is dependent on how the lower level form is created.
    • Options for adding a new form
      • Modify:
        • The parent form governs the child form with some exceptions.
        • The sections on the inherited form cannot be set to Not Shown nor can the section be modified at the field level (no new fields can be added or fields removed)
        • A lower level unit can add new sections. These sections will only be shown to the lower level unit’s faculty.
        • The only form that can be shown via the Activities on the toolbar is the Activity Input form. Administrators can modify the Activity Input form for a particular unit - it will inherit any sections shown on higher level unit form and administrators can add additional sections to display.
        • Note: The activity input form which determines which sections faculty will ‘see’ when clicking on the Activities link on the menu MUST be cloned from the Level 1 form using the MODIFY option.
      • Add:
        • The parent form does not impose governance to the lower level form.  
        • This creates risk for shared sections on that form. If the section is modified at the lower level, the modification will apply to the version of the section on every form.
        • Sections can be added or removed from the form (Set to Shown or Not Shown)
        • Activity Classifications can be added or removed.

Forms, Sections, and the Unit Hierarchy

If a section is set to display at a unit level, it will display for all units below it on all modified forms (both Profile and Activities).

Diagram KEY:

  • A through E = sections
  • DNS = section set to ‘do not show’
How Sections and Fields work (last updated 7/2/2019) - Google Docs
Locked Sections

The error that appears when you try to “Do Not Show” a section that is shown at a higher level.

How Sections and Fields work (last updated 7/2/2019) - Google Docs

Section Visibility Rules:

  • Sections listed as ‘Show’ - visible to all units, must be used by all units
    • Ex. A and B
  • Sectiosn set to ‘Do Not Show’ at university level - available to be ‘shown’ at lower unit levels
    • Ex. D: not shown at L1 University or L2 College, but shown at L3 Department

On added Activities forms, sections do not respect the inherited show/do not show. This ONLY applies to forms created through the “add” process. This is to allow a different combination of sections to be pushed out for initiated periods of input.

Diagram KEY:

  • A through E = sections
  • DNS = section set to ‘do not show’
How Sections and Fields work (last updated 7/2/2019) - Google Docs

Section Configuration Best Practices:

  • Section management (creation / modification) handled by the Level 1 administrator.
  • Sections should be created at the university level and managed for lower level units.  This allows for expansion of section use. (EX:  College A request that Section A be created. College B does not want to use Section A.  Three months later, College B decides that it does want to use Section A.  If Section A had been created at the College A unit level, there would be no opportunity for College B to have access to Section A.)
  • Use Activity Classifications for unit-specific data points
    • Ex. L2 College A and L2 College C want additional unit specific fields within section C; both units use section C, but can have different Activity Classifications that are specific to their unit and only visible to faculty within their unit

Data in Sections:

Sections are made up of both fields and activity classifications. Fields are consistent across units while activity classifications can be unit-specific. 

Here is the set up for the Scholarly Contributions and Creative Productions section. The fields are default (cannot be customized) and there are twelve activity classifications attached to the section. All activity classifications that should show for any unit should be listed on the section - the unit-specificity is set in the activity classification itself.

Data in Sections:Fields and Activity Classifications

Exclude Units

Within Activity Classification, you choose which units to exclude.

Within Activity Classification, you choose which units to exclude.

This can be done by checking units - it will automatically select all units below but an administrator can un-select as needed.

This can be done by checking units - it will automatically select all units below but an administrator can un-select as needed.

Options to associate Activity Classifications to sections:

Rather than manually add an activity classification to a section, this can be done via the Activity Classification itself. This will still respect the excluded units set in “Exclude These Units.” The sections available here are the sections in the university Activity Input form.

Options to associate Activity Classifications to sections:

This is how the Scholarly Contributions and Creative Productions: Book looks for the College of Business (11 Activity Classifications):

This is how the Scholarly Contributions and Creative Productions: Book looks for the College of Business (11 Activity Classifications)

This is how the Scholarly Contributions and Creative Productions: Book looks for the College of Science (7 Activity Classifications):

The Scholarly Contributions and Creative Productions: Book

Reporting:

  • In order to report across units, the same section must be used.
  • Unit-specific reporting can be done by adding activity classifications to the section.

Reports to use:

  • Activity Input Report: allows you to report on the same section (fields) across the institution
    • Ex. Report on Section B across all units
    • Ex. Report on Section C for College A’s additional activity classification across the college