Overview

The Enable ID Validations setting controls whether Classter automatically checks that the Tax Registration Number and Social Security Number entered for people and organizations in the system are correctly formatted before a record can be saved. Instead of accepting any text typed into these fields, Classter verifies that the value follows the expected format and passes a check-digit calculation that catches common typing mistakes.

This setting is not a simple on/off switch. It opens a dedicated configuration screen where an institution can define one or more validation rules, each specifying which type of record it applies to, which identification number it checks, and how strict the check should be.

Setting reference: Enable ID Validations / Id_Validations (Settings > Basic Customization > Controls, Filters and Checks)

What This Setting Does

When one or more validation rules are configured, Classter adds a format check to the Tax Registration Number and/or Social Security Number field of the record types the rule applies to. The check runs when the field is filled in and again when the record is saved.

Two identification number types can be validated:

• Tax Registration Number (also known as a taxpayer number or fiscal ID number)
• Social Security Number (a personal social insurance / social security identifier)

For each rule, the institution chooses:

• Which type of record the rule applies to (see ‘Where It Is Used’ below)
• Which of the two ID types to validate
• How strict the rule is: Block (the record cannot be saved until the value is corrected) or Warning (the value is checked, but see the note under Business Logic / Behavior about this level)
• Whether an empty field is allowed to skip the check, so the rule only fires when a value is actually entered
• Optionally, whether the rule should only apply to specific groups of people, such as certain student categories, nationalities, or countries of a person’s main address

At this time, the only validation format available checks numbers against a well-known national format: a 9-digit Tax Registration Number and an 11-digit Social Security Number, each with its own internal check-digit logic that catches common mistakes such as transposed or mistyped digits. If your institution operates where this specific format does not apply, simply leave the corresponding rule unconfigured.

Where It Is Used

Validation rules created through this setting can apply to the following areas of the application:

• Student profile and registration forms
• Teacher profile forms
• Parent / relative profile forms
• Other Contacts (for example, partner or external contact) profile forms
• Company records (for example, the payer / organization information used for invoicing)
• The Re-registration form used when returning students renew their enrollment
• The Admission Portal (the staff-facing admission and enrollment management screens)
• The public Admission Sign-up form (the online form prospective students or applicants fill in themselves)

The check is triggered whenever a Tax Registration Number or Social Security Number field is entered or edited on one of the forms above, and again when the record is saved.

Business Logic / Behavior

• Multiple rules can exist at the same time (for example, one rule for Students, another for Teachers, another for the online Admission Sign-up form), each with its own configuration.
• A rule set to Block: if the value entered does not pass the format check, the record cannot be saved and the user sees a message explaining that the Tax Registration Number or Social Security Number is not valid, until it is corrected.
• A rule set to Warning: the value is still checked against the format rules, but this level is intended to be less strict than Block. Treat Warning as a softer option and confirm its exact on-screen behavior in your environment, since it may not display a visible message in every area of the application.
• For the Admission Portal, the Re-registration Form, and the public Admission Sign-up form, the rule always behaves as Block and cannot be set to Warning. This protects data quality at the point where a person’s information first enters the system, which is often the hardest moment to correct later.
• If Allow empty values is selected for a rule, a blank ID field is accepted without triggering the check. If it is not selected, a value must be entered and it must pass the format check.
• Rules can be limited to specific groups: an institution can apply a rule only to certain student categories, only to certain nationalities, or only to people whose main address is in certain countries. This allows different validation behavior for local versus international records, since a foreign resident’s identification number will usually not follow the local format.
• A staff member whose role has been granted the separate permission ‘Disable ID validation rules for this user’ is not subject to any of these rules; all ID validation is skipped for that person’s own use of the system. This is intended as a controlled override for staff who may need to enter special-case data, for example when helping register a family with a temporary or foreign identification number.
• This setting behaves the same way in K-12 Mode and in Higher Education Mode. No difference in behavior between the two modes was found.

Example(s)

Example 1 – Blocking format check for local Students

Sunrise Academy configures a rule for Students that checks the Tax Registration Number, sets the rule to Block, leaves Allow empty values unchecked, and does not restrict it to any nationality or country. When an administrator registers a new student and enters ‘12345678’ (8 digits) into the Tax Registration Number field, Classter rejects the save and shows a message indicating the number is not valid because it does not match the required format. Once the administrator corrects the entry to a properly formatted 9-digit number that passes the check, the record saves successfully.

Example 2 – Restricting a rule to local nationals only

Bright Path International School wants to validate the Social Security Number for Students, but only for students who hold local nationality, since international students often do not have a local Social Security Number. The school creates a rule for Students with ID type Social Security Number and restricts it to the local nationality only. Students with any other nationality can leave the field blank or enter a foreign identifier without triggering the check, while local students must provide a correctly formatted number.

Example 3 – Public Admission Sign-up form

Green Valley College uses an online Admission Sign-up form for prospective students to self-register. Because this entry point always behaves as Block, an applicant who mistypes their Tax Registration Number sees an on-screen error immediately and must correct it before the application can be submitted, preventing incorrectly formatted identification numbers from entering the system at the source.

When to Use

When to Enable

• Your institution operates where a standard, checkable format for Tax Registration Numbers or Social Security Numbers is used, and you want to reduce data-entry mistakes.
• You want to guarantee that identification numbers collected through online admission or re-registration forms are correctly formatted before an application is even submitted.
• You need different validation behavior for local versus international records, using the nationality or country scoping options.
• You want specific administrative staff to be able to override validation in exceptional cases, using the separate per-role permission designed for that purpose.

When to Disable (or leave unconfigured)

• Your institution operates where the built-in format check does not apply, since only one national format is currently supported, and enforcing it would incorrectly reject valid data.
• You collect identification numbers from a very international population where most records will not match the supported format, and scoping rules to exclude them have not yet been set up.
• You are still migrating or cleaning up historical data that may contain identification numbers in an inconsistent format, and you do not want existing records to block saves until the data is corrected.

Notes

• This is a multi-rule configuration screen, not a single toggle. An institution can define as many rules as needed, each targeting a different record type, ID type, and audience.
• Only one validation format is currently supported. If your institution’s Tax Registration Number or Social Security Number does not follow this format, do not configure a rule for that ID type, or valid values may be incorrectly rejected.
• Related setting: Enable Automated Academic Registration Numbering / Enable_Automated_Academic_Registration_Numbering (Settings > Student Form > Default Values) – controls automatic generation and formatting of a Global Registration Number, a separate type of identifier that can be used instead of a Tax Registration Number or Social Security Number on admission forms.
• Related setting: Use of Student Register Categories (Settings > Basic Customization > Core Entities Settings) – if student categories are not enabled and configured, the category-based scoping option in this setting cannot be used meaningfully.
• Related permission: Disable ID validation rules for this user / DisableIdValidationRulesForThisUser (User Roles > Rights) – a per-role permission that, when granted, exempts a staff member from all ID validation rules configured here.
• Prerequisite: if you plan to scope a rule to specific student categories, nationalities, or countries, make sure those lists are already set up and populated for your institution, since scoping is only useful once those options exist to choose from.
• This feature is education-level-agnostic: no differences were found between K-12 Mode and Higher Education Mode.