Overview
This article explains the “Default expiration date” setting, found in the Card Settings section of the system’s Basic Customization configuration. This setting controls whether identification cards issued to Students, Teachers (Educators/Lecturers), Employees (Staff), and Relatives (Parents/Guardians) automatically receive an expiration date when they are created, and, if so, how that date is worked out.
What This Setting Does
This is a single-choice (dropdown) setting with two options:
– Never (default) – newly created cards do not receive any automatic expiration date. The card remains valid indefinitely unless a staff member manually sets an expiration date on that specific card later on.
– Academic Period – newly created cards automatically receive an expiration date equal to the end date of the academic period (term, semester, or school year, depending on how the institution’s calendar is configured) that is active at the moment the card is created.
The setting only applies at the moment a new card is generated. It does not retroactively change cards that already exist before the setting was changed. In addition, the expiration date produced by this setting is only a starting/default value – staff can always open an individual person’s card record afterward and manually set, change, or clear that card’s own expiration date, regardless of what this setting says.
Where It Is Used
This setting is applied automatically whenever an identification card is created for any of the following types of people:
– Student
– Teacher (Educator/Lecturer)
– Employee (Staff)
– Relative (Parent/Guardian)
It applies whether the card is created manually by a staff member from the person’s Card section, or automatically when the person’s profile is created (if automatic card creation is enabled for that category of people).
It also applies when a digital wallet version of the card is generated (for example, an Apple Wallet or Google Wallet pass). The expiration date produced by this setting is carried over to the digital pass as well, so the digital version shows the same validity period as the physical card.
Finally, the resulting expiration date affects how the card behaves in card management, scanning, and benefit-verification screens – for example the card’s Active/Inactive indicator, access-control or attendance scanning at gates, and verification of card-linked benefits or discounts (such as at a canteen or point-of-sale terminal).
Business Logic / Behavior
– The default value for this setting is Never – unless an administrator changes it, cards will not expire automatically.
– When Academic Period is selected, a new card’s expiration date is set to the end date of the academic period that is current at the moment the card is created. If a later academic period is defined afterward, it does not change the expiration date of cards that were already issued.
– A card whose expiration date has passed is treated as inactive for scanning, access, and benefit-verification purposes – even if the underlying Student, Teacher, Employee, or Relative record is still active in the system. Such a card will not be accepted until it is reissued or its expiration date is updated manually.
– This setting only supplies the default expiration date used when a card is first created. A staff member can still open any individual card record and set or clear its expiration date manually at any time, regardless of what this setting is configured to.
– Interaction with cross-period cards: if a category of people (for example Employees) is configured elsewhere to use cross-period cards, their cards remain valid across multiple academic periods and are not automatically expired at the end of a single period, even if this setting is set to Academic Period.
– K-12 versus Higher Education mode: this setting behaves identically in both modes. Whether the institution uses K-12 terminology (such as school year or term) or Higher Education terminology (such as semester or academic year), the Academic Period option always follows whichever academic period is currently active for the person involved. There is no separate or different behavior in Higher Education mode.
Prerequisites:
– A Card Template should already be configured for each category of person (Student, Teacher, Employee, Relative) that the institution intends to issue cards to.
– The start and end dates of the current academic period must be correctly set up in the academic calendar, since the Academic Period option relies on that end date to calculate a card’s expiration date.
Examples
Example 1 – Setting is Never
Greenfield Academy leaves this setting on Never. When a new student, Jamie Rivera, is enrolled, an ID card is issued automatically. The card has no expiration date, so Jamie can keep using the same card every year without it needing to be reissued, as long as Jamie remains enrolled and the card itself is not lost, damaged, or manually deactivated.
Example 2 – Setting is Academic Period
Riverside Institute sets this setting to Academic Period. The current semester runs from 1 February to 30 June. When a new card is issued to employee Alex Moreno on 15 February, the card automatically receives an expiration date of 30 June. From 1 July onward, unless Alex’s role has been included in the cross-period cards setting, the card will show as inactive at access-control points until a new card is issued for the next semester, or its expiration date is manually updated by staff.
When to Use
When to select Never
– The institution wants a single, long-lasting card per person, reissued only when it is lost, damaged, or when personal details change.
– Cards double as a long-term identification document and the institution does not want to reprint or reissue cards every term or year.
When to select Academic Period
– The institution wants cards – or at least certain categories of card, such as Student cards – to automatically stop working once the current term, semester, or year ends, for security reasons or to require a renewal check at the start of each new period.
– The institution ties time-limited access or benefits to the card (for example canteen discounts or library access) that should not continue automatically once a person’s current period of enrollment or employment segment ends, without staff reviewing it first.
– The institution wants to combine this with the cross-period cards setting, so that certain categories of people (for example permanent staff) are exempted from automatic expiration, while cards for other categories (for example students) still expire at the end of each period.
Notes
Related settings (all found in the same Card Settings section):
- Set ID/Code type to be used in Student cards/FormatStudentIdCards (Configuration > Main Settings > General Settings > Basic Customization > Card Settings)
- Set ID/Code type to be used in Teacher cards/FormatTeacherIdCards (Configuration > Main Settings > General Settings > Basic Customization > Card Settings)
- Set ID/Code type to be used in Employee cards/FormatEmployeeIdCards (Configuration > Main Settings > General Settings > Basic Customization > Card Settings)
- Set ID/Code type to be used in Relative cards/FormatRelativeIdCards (Configuration > Main Settings > General Settings > Basic Customization > Card Settings)
- Auto-create Cards upon entity creation for the following entities/AutoCreateCardsUponEntityCreation (Configuration > Main Settings > General Settings > Basic Customization > Card Settings)
- Enable Cross Period cards for the following entities/EnableCrossPeriodCardsForEntities (Configuration > Main Settings > General Settings > Basic Customization > Card Settings) – works directly together with this setting, see the Business Logic section above.
- Enable QR code for benefits/EnableQRCodeForCardsBenefits (Configuration > Main Settings > General Settings > Basic Customization > Card Settings)
- Enable external verification page for benefits/EnableExternalVerificationPageForCardsBenefits (Configuration > Main Settings > General Settings > Basic Customization > Card Settings)
This setting applies institution-wide – it is not configured separately per academic period, per user, or per role. Once it is changed, it affects all new cards created afterward across the whole institution.
Changing this setting does not affect cards that have already been issued. Only new cards created after the change will follow the new rule.