Overview
This setting controls how far back in time a user is allowed to set the effective date when changing a student’s status (for example, moving a student from Active to Withdrawn, or from Applicant to Registered). It protects the accuracy of student status history by preventing status changes from being backdated further than a number of days that the institution decides is acceptable.
The setting applies the same way regardless of whether the institution operates in K-12 mode or in Higher Education (College) mode – there is no difference in how it behaves between the two modes. See section 4 for details.
What This Setting Does
Whenever a user changes a student’s status, Classter asks the user to confirm the date on which the change should take effect (the “change status date”). This setting defines the maximum number of days that this date is allowed to be earlier than today’s date.
In practice:
- The value entered is several days (for example, 5, 10, or 30).
- Classter compares the system’s current date with the change status date chosen by the user.
- If the change status date is further back than the configured number of days, the change is not accepted and the user is warned on screen.
- If this setting is left empty, there is no restriction at all – any past date can be used when changing a student’s status. This is the default, out-of-the-box behavior until an institution decides to configure a limit.
This setting only restricts how far back the date can be. It does not affect or restrict setting a status change date in the future.
Certain staff roles can be granted a specific permission that lets them bypass this restriction completely, so they can record a status change on any past date regardless of the configured limit. This is typically reserved for senior administrative staff who occasionally need to make historical corrections (see “Prerequisites” in section 7).
Where It Is Used
Location in the application:
- Settings > General Customizations > Student Form > Status Management
This setting affects users whenever they change a student’s status, in any of the following places:
- Changing the status of a single student from the student’s profile (the “Change Status” action).
- Changing the status of multiple students at once from the student list (mass / bulk status change).
- Editing the status or the status date directly within a student’s registration/status list.
The restriction is enforced in two ways at the same time: the screen where the date is chosen will immediately warn the user and prevent saving if the date is too far back, and the system also validates the same rule centrally when the status change request is actually processed. This means the limit applies consistently everywhere a status change can be made, including bulk updates – it cannot be bypassed simply by using a different screen.
Business Logic / Behavior
Comparison rule: Classter subtracts the change status date chosen by the user from today’s date. If the result is greater than the number of days configured in this setting, the change is rejected for that student.
Business rules that can be inferred from this setting:
- Backward-looking only: the restriction only limits how far in the past the change date can be. A future-dated status change is not affected by this setting.
- Per-student evaluation in bulk changes: when changing the status of many students at the same time, only the students whose chosen date breaks the rule are rejected; the rest of the batch is saved normally.
- Role-based override: a dedicated permission can be assigned to specific roles to exempt them from this restriction entirely, allowing full flexibility for trusted staff while keeping the restriction in place for everyone else.
- No restriction by default: until an institution enters several days in this setting, there is no limit at all – this is an opt-in control, not a restriction that is active from day one.
K-12 vs. Higher Education (College) Mode
This setting behaves identically whether the “Enable Configuration for Higher Education” setting (see section 7) is switched on or off. There is no separate configuration, default value, or exception for Higher Education / College mode – the same number of days, the same comparison rule, and the same role-based override apply equally to K-12 and Higher Education institutions.
Example(s)
Example 1 – Single status change
Sunrise Academy has configured this setting with a value of 5 days. Today is 12 April.
A registrar opens the profile of student Alex Morgan and changes the status from Active to Withdrawn, setting the change status date to 3 April (9 days back). Since 9 days is greater than the configured limit of 5 days, Classter displays a warning and prevents the change from being saved, indicating that the earliest acceptable date is 7 April.
The registrar corrects the date to 8 April (3 days back, within the 5-day limit) and the status change is saved successfully.
Example 2 – Bulk status change
The same institution runs a mass status change for 30 graduating students, all being moved from Active to Graduated with a change status date of 20 June. Two of these students were entered with an earlier date of 1 June, which falls outside the 5-day limit. Classter saves the status change for the other 28 students normally, while flagging only those 2 records as rejected so the registrar can correct their dates individually.
Reference Walkthrough
Main Settings / General Settings /Student Form / Status Management / The status change can be up to X days back
When a user changes the student’s status, Classster will ask the user to set a change status date. Here we can define how many days back this date can be. The comparison is between the system’s current date and the date set by the end user. If the time period between the system current date and the date set by the end user is greater than the selected option, a pop-up warning will appear on the screen.
Setting -> Active -> 1 (Figure 1)
From the Student list, we select the pupil whose status we want to change. Then click on the option “change status,” which can be found in actions.
Figure 1
Changing the status and setting the date of change to 23/8/2021, while having the current date 25/8/2021, will result in a pop-up warning appearing on the screen. (Figure 2 , Figure 3)
Figure 2
Figure 3
When to Use
When to Enable
- The institution needs to keep an accurate, auditable history of when student status changes actually took effect (for example, for compliance, reporting, or funding purposes).
- Status changes influence other processes such as attendance, financial arrangements, or reporting, where an unrestricted backdated change could create inconsistencies.
- Several staff members are able to change student status, and administrators want a safeguard against accidental or excessive backdating.
When to Disable (Leave Blank)
- The institution is small, and only trusted administrative staff can change student status, and backdating is rarely, if ever, an issue.
- During an initial data setup or migration, when historical status records need to be entered with genuinely old dates. Once the setup is complete, a limit can be configured for ongoing use.
- If a limit is generally desired but a few staff members legitimately need to backdate changes from time to time, consider keeping the setting enabled and instead granting those specific staff the role-based override described in section 7, rather than disabling the restriction for everyone.
Notes
Prerequisites
- None are required simply to configure the number of days for this setting.
- If certain staff should be exempt from this restriction, the appropriate permission must first be granted to their role by an administrator before this exemption takes effect for them.
Related Settings
The following settings are located in the same area or otherwise interact with student status changes:
- “Set default pre-selected student status” (“Student Form > Status Management – Proepilegmeni_Katastasi_Mathiti”): defines which status is pre-selected by default for students.
- “Use additional change reason in status change” (“Student Form > Status Management – Use_Second_Change_Reason_Status”): adds an extra reason field to the change status form.
- “Forbid end users from changing the initial default student status” (“Student Form > Status Management – Locked_New_Student_Status”): locks the initial status field so it cannot be changed by end users.
- “Student Status Change Workflow” (“CRM Settings > CRM Status Workflow – StudentStatusChangeWorkflow”): defines the workflow of reasons/steps followed when a student’s status changes.
- “Readjust Arrangement when changing student to…” (“Arrangements Parameters > Arrangement Modifications – Anaprosarmogi_Diakaninismou_ana_katastasi”): defines for which statuses a student’s financial arrangement is automatically readjusted.
- “Enable Configuration for Higher Education” (“Higher Education Customization > Basic Settings – Xrisi_parametropoihshs_kolegiou”): switches the application between K-12 and Higher Education (College) mode. As noted in section 4, this setting’s behavior is not affected by that mode.
Note: A dedicated permission (not a setting) can be granted to specific staff roles to exempt them from this restriction entirely, letting them record status changes on any past date. This permission should be assigned carefully, and only to staff who are trusted to make historical corrections responsibly.
