Overview

Setting name: If the Student date of birth is not given, then consents are answered by (If_The_Students_Date_Of_Birth_Is_Not_Given_Then_Consents_Are_Answered_By)

Location: Configuration > Main Settings > General Settings > ‘Basic Customization’ tab > ‘Consents Management’ section

Setting type: Single choice (dropdown) with two options: Parents (Guardian) or Students

This setting controls a specific, narrow situation that can occur when the system is asking a _Student’s_ family (or the _Student_ personally) to answer a Consent – a permission or agreement form, such as consent to use personal data, photos, or participation in a school trip. Normally, Classter automatically decides whether the _Student_ or their Parent (Guardian) should answer a Consent, based on the student’s age. This setting exists to cover the case where that automatic, age-based decision cannot be made because the Student’s date of birth has not been recorded in the system yet.

In short: this is a fallback rule, used only when a student’s date of birth is missing, that tells Classter who should be allowed to answer Consents on that Student’s behalf – the Parent (Guardian) or the _Student_ themselves.

What This Setting Does

When a Consent needs to be answered for a _Student_, Classter must decide who is allowed to see and complete it: the _Student_, or a Parent/Guardian acting on the _Student’s_ behalf. This decision is normally based on age – younger _Students_ are considered minors and their Parent/Guardian answers for them, while _Students_ who have reached a configured ‘coming of age’ threshold answer for themselves.

If the _Student’s_ date of birth has not been entered anywhere in the system, Classter has no way to calculate an age, and therefore cannot apply the normal age-based rule. This setting is the fallback that is used instead. It lets the institution choose, in advance, one of two options:

• Parents – if the date of birth is missing, treat the _Student_ as a minor by default, and require the Parent/Guardian to answer the Consent.
• Students – if the date of birth is missing, treat the _Student_ as capable of answering, and let the _Student_ answer the Consent directly.

This setting applies only to items categorized as Consents. It does not affect other kinds of admission or registration documents/data requests (for example, uploading a certificate or filling in contact details), which follow their own separate rules.

Where It Is Used

This setting is checked automatically, in the background, every time Classter needs to display or validate Consents for a _Student_ whose date of birth is not on file. In practice, this can occur in any of the following places:

• Online Admission application – when a new applicant (or the person completing the application on the applicant’s behalf) reaches the Consents step of the application form.
• Registered Student Portal – when a currently enrolled _Student_ logs in and is asked to answer one or more Consents (for example, a new Consent that was introduced after enrollment).
• Parent Portal – when a Parent/Guardian logs in on behalf of their child and is asked to answer Consents for that child.
• Online Re-Registration – when a returning _Student_ goes through the re-registration process and Consents are requested again as part of that process.
• Consent invitation links sent by email – when the institution sends a direct link (with or without a signature request) inviting a _Student_ or Parent to review and answer a specific Consent.

In every one of these places, this setting only comes into play at the exact moment a Consent is being shown or validated for a _Student_ record that has no date of birth recorded. As soon as a date of birth is entered for that _Student_, Classter switches back to the normal, age-based rule for all future Consents, and this setting no longer affects that _Student_.

Business Logic / Behavior

Normal rule (date of birth known)

When a _Student’s_ date of birth is available, Classter calculates the _Student’s_ current age and compares it against a maturity age threshold. This threshold comes from either:

• A specific ‘Maturity Age’ value set individually on that particular Consent (when the institution wants a particular Consent to use a different age than usual); or, if that is not set,
• The general ‘Coming of Age’ setting, which defines the default age of maturity for the whole institution.

If the _Student_ is younger than the applicable threshold, the Consent is directed to the Parent/Guardian. If the _Student_ is at or above the threshold, the Consent is directed to the _Student_.

Fallback rule (date of birth missing) – this setting

When the date of birth is missing, blank, or not a valid date, Classter cannot calculate an age at all, so the comparison above cannot happen. Instead, Classter looks directly at this setting and uses whichever option has been selected – Parents or Students – to decide who may answer the Consent, regardless of the _Student’s_ actual age.

Business rules that can be inferred from this behavior

• This setting is only ever consulted when a date of birth is missing. If a date of birth exists, this setting is ignored completely, even if it has a value configured.
• The choice is institution-wide by default: whichever option is selected here becomes the default answer for every _Student_ with a missing date of birth, across Admission, Registration, Re-Registration, and Portal self-service.
• This is a binary either/or choice – there is no option to allow both the Parent and the _Student_ to answer at the same time specifically because of this setting.
• This setting is a safety net for incomplete data, not a substitute for entering the date of birth. Institutions are expected to still collect the _Student’s_ real date of birth as soon as it becomes available.

Prerequisite to be aware of: This fallback only becomes relevant for Consents that actually have an age requirement configured for them, either through the general ‘Coming of Age’ setting or through that Consent’s own ‘Maturity Age’ field. If an institution has never configured any maturity/age-of-majority value anywhere, age-based routing does not apply to that Consent in the first place, and this setting will have no practical effect on it – the Consent may be visible to both the Parent and the _Student_ regardless of this setting’s value. For this setting to reliably control who answers, make sure the ‘Coming of Age’ setting (or the specific Consent’s ‘Maturity Age’ field) is configured.

Example(s)

Example A – Setting configured to ‘Parents’

Lakeside International School has set the general ‘Coming of Age’ to 18, and has configured ‘If the Student date of birth is not given, then consents are answered by’ to Parents. A new applicant, Alex Morgan, starts an online admission application, but the date of birth field was left empty when the applicant reached the Consents step (for example, because a staff member is completing the application on the family’s behalf and has not yet obtained that detail).

Because no date of birth is available for Alex Morgan, Classter cannot calculate an age to compare against the ‘Coming of Age’ threshold of 18. It falls back to this setting instead, which is set to Parents. As a result, the required Consents (for example, a photo/media release form) appear on the Parent Portal for Alex’s parent, Taylor Morgan, to review and answer – they do not appear on Alex’s own applicant view until a date of birth is entered.

Example B – Setting configured to ‘Students’

Brightwood Institute, a vocational training center that primarily enrolls adult learners, has configured the same setting to Students instead of Parents. Another applicant, Jamie Lee, also submits an application without a recorded date of birth.

In this case, because the setting is configured to Students, Classter presents the Consents directly on Jamie Lee’s own applicant portal for Jamie to answer personally – no Parent/Guardian involvement is required, even though Jamie’s exact age is unknown to the system at that point.

When to Use

When to set this to ‘Parents’

• The institution primarily serves minors (for example, a K-12 school, a children’s language center, or a youth training program), where the safer default is to assume a _Student_ with an unknown date of birth is not yet old enough to answer on their own.
• The institution wants to minimize the risk of a minor answering a legally or administratively sensitive Consent (such as data protection or media consent) without parental awareness, in case the date of birth is simply missing due to a data-entry gap.

When to set this to ‘Students’

• The institution primarily serves adult learners (for example, a college, university, or professional/adult training center), where the safer and more efficient default is to assume a _Student_ with an unknown date of birth is an adult capable of answering directly.
• The institution wants to avoid unnecessary delays or friction caused by routing Consents to a Parent/Guardian when, in practice, the vast majority of enrollees are adults and providing a date of birth is simply not yet completed in the workflow.

Whichever option is chosen, it is good practice to encourage front-office staff and applicants to complete the date of birth field as early as possible in the process. Once a date of birth is on record, Classter relies on the actual age instead of this fallback setting, which gives a more accurate and individualized result for each _Student_.

Notes

K-12 Mode vs. Higher Education Mode

This setting behaves identically in both K-12 mode and Higher Education mode (the mode controlled by the ‘Enable Configuration for Higher Education’ setting). There is no difference in the underlying logic between the two modes – the same two options (Parents / Students) are available, and the same fallback behavior applies, regardless of which mode the institution operates in. The only variation end users may notice is that the word used for ‘_Student_’ in the setting’s label and throughout the interface may be displayed using the institution’s own configured terminology (for example, ‘Learner’ instead of ‘Student’), which is a general terminology customization and not specific to this setting.

Prerequisites

• The Consents feature itself must be in use – that is, the institution must have at least one active Consent item configured (under the Consents & Admission Data management area) and, for the Admission application specifically, the setting that enables Consents during application submission must be turned on.
• For this setting to have a practical effect, an age threshold should be configured somewhere – either the general ‘Coming of Age’ setting, or the ‘Maturity Age’ field on the specific Consent in question (see the Business Logic section above).

Related Settings

• ‘Coming of age’ (‘Main Settings > General Settings > Student Form > Checks & Controls’ – Hlikia_enilikiwshs_mathiti) – the general age threshold Classter uses to decide who answers Consents whenever the Student’s date of birth IS known; this setting only takes over when that calculation is not possible.
• ‘Use Digital Signature’ (‘Main Settings > General Settings > Basic Customization > Consents Management’ – UseDigitalSignature) – enables signature capture when a Consent is answered.
• ‘Remove Close/Cancel Button From Forced Consents Dialog’ (‘Main Settings > General Settings > Basic Customization > Consents Management’ – Remove_CloseCancel_Button_From_Forced_Consents_Dialog) – controls whether a user can dismiss a mandatory Consent pop-up without answering it.
• ‘Employee Receiving Consent Modifications Notifications On Edit’ (‘Main Settings > General Settings > Basic Customization > Consents Management’ – Employee_Receiving_Consent_Modifications_Notifications_OnEdit) – designates a staff member to be notified whenever a previously submitted Consent answer is edited.
• Enable Consents during application submission (‘Configuration > Admission > Admission Settings > Applicants Portal tab > Basic Settings’ – Consenting_Form_Enabled) – turns the Consents step on or off for the online Admission application; must be enabled for Consents to appear there at all.

In addition, each individual Consent (configured under Consents & Admission Data management) has its own ‘Maturity Age’ field, which overrides the general ‘Coming of Age’ setting for that specific Consent only, and its own ‘Hide Consents From Admission’ option, which can hide a particular Consent from the Admission Portal while still requesting it from already-registered Students. These are per-Consent fields rather than global settings, and are configured directly on each Consent record.