Overview

The Enable Cross Period Cards for the Following Entities setting controls whether a person’s identification card (ID card) remains the same and stays valid across multiple academic periods (terms, semesters, or years), instead of each academic period being treated as needing its own separate card.

An ID card in Classter is a printable or digital identification card, typically encoded with a barcode or QR code, used to identify a person, look them up quickly, verify eligibility for benefits, and support activities such as attendance, access, or transportation check-in where those are in use. By default, Classter treats card issuance as tied to the academic period a person is currently registered in – when someone continues into a new period, the system may expect or create a card that belongs specifically to that new period.

This setting lets an institution choose, separately for four types of people – _Students_, Teachers, Employees (Staff), and Relatives (Parents/Guardians) – to instead give that type of person a single card that carries over unchanged across every academic period, rather than a new one being expected each time.

What This Setting Does

This setting is a multi-select list. The administrator chooses which of the following entity types should keep one single card across all academic periods, instead of a new card being expected for each period:

• _Students_ – A _Student_’s ID card remains valid and is reused across every academic period they are enrolled in, instead of a new card being expected each time they are re-registered into a new period.
• _Teachers_ – A Teacher’s ID card carries over unchanged from one academic period to the next.
• Employees – An Employee’s (Staff) ID card is treated as a single, ongoing card that is not tied to any particular academic period.
• Relatives – A Relative’s (Parent/Guardian) ID card remains the same across academic periods, even as their linked _Student_(s) move from one period to the next.

If an entity type is not selected in this setting, that type follows the standard behavior: the system looks for a card that belongs specifically to the current academic period, and if the person’s existing card belongs to a previous period, they are treated as not yet having a card for the new one.

By default, this setting is empty, meaning every entity type follows the standard one-card-per-academic-period behavior until an administrator explicitly enables cross period cards for a given type.

Where It Is Used

This setting is checked automatically, in the background, wherever the system needs to find or confirm a person’s ID card. Staff do not see or interact with this setting directly while performing these actions – they simply notice that the existing card continues to be recognized, if the corresponding option is enabled:

• Checking whether a person already has a card – for example, when a _Student_ or Teacher is re-registered into a new academic period and the system decides whether a new card is needed.
• Generating or refreshing a digital pass added to a mobile wallet (Apple Wallet / Google Wallet) – determines whether the existing pass keeps working into the next period without needing to be reissued.
• Verifying a card by scanning its QR code, for example to confirm eligibility for a benefit or service.
• Automatic check-in on a transportation (bus) route when a card is scanned or tapped.
• _Student_ or staff list views and reports that show whether a card has been printed, delivered, or created for the current period – these take cross period cards into account so that a person is not shown as missing a card for the new period when they already hold one that is meant to last across periods.

This setting applies uniformly across the whole institution – it is not possible to enable cross period cards for one Location (Campus/School) or Grade (Year/Program) but not another.

Business Logic / Behavior

The following behavior can be confirmed directly from the setting’s design:

• Nothing changes for an entity type unless it is explicitly selected. Leaving the list empty (the default) means every entity type keeps the standard behavior of a separate card per academic period.
• When an entity type is selected, and the system checks whether a person already has a card for the current academic period, it accepts and reuses a card issued in any previous academic period, rather than requiring one issued specifically for the current period. In practice, that person keeps using the same physical or digital card indefinitely, instead of a newly issued one being expected every period.
• This works together with the Auto-Create Cards Upon Entity Creation setting (see Related Settings): when a person continues into a new academic period, if their entity type has cross period cards enabled, the system reuses their existing card instead of generating a new one – so no duplicate card is created for the new period, even if automatic card creation is also switched on. If cross period cards is not enabled for that entity type, automatic card creation can still generate a fresh card for the new period as usual.
• Separately, the Default expiration date setting (see Related Settings) can be configured to expire cards automatically at the end of an academic period. When cross period cards is enabled for an entity type, that automatic period-end expiration is not applied to that type – a cross period card is not cut short simply because one academic period has ended.
• Cards recognized through cross period retention continue to work consistently for benefit verification (QR code scanning) and transportation check-in, without being tied to whichever academic period is currently active.

Assumption (not directly confirmed in the setting’s own logic, but consistent with its purpose and naming): this setting exists to reduce the cost, administrative effort, and inconvenience of reprinting and redistributing physical cards, or reissuing digital wallet passes, to the same people every single academic period, for institutions and entity types where an individual’s card does not need to change in appearance or data from one period to the next.

Example(s)

Example 1 – K-12 school, Employees enabled, Students left at default

Riverside Grove Academy prints Student ID cards that also display the child’s current grade and class, so the school does not enable cross period cards for Students – every September, when Students are re-registered into the new academic year, a fresh card is produced showing their new grade. However, Riverside Grove does enable cross period cards for Employees, since staff badges do not need to change every year: a teaching assistant named Marcus Webb keeps the exact same staff badge year after year, without the front office needing to reissue it each September.

Example 2 – Higher Education college, Students and Teachers enabled

Brightfield Institute of Technology runs multi-semester degree programs and enables cross period cards for both Students and Teachers (labeled Lecturers, since the college operates in Higher Education mode). A student named Priya Nandakumar receives her campus ID card, including a mobile wallet pass, in her very first semester. As she progresses into her second and later semesters, the same card and wallet pass continue to work for building access and benefit verification without being reissued – saving the college the cost and delay of reprinting a card and reloading a wallet pass every semester. If Brightfield later enabled this setting for Relatives as well, a parent linked to a Student would similarly keep one card for as long as their child remains enrolled, across every semester.

When to Use

When to Enable

• The institution wants a specific group of people (for example, Employees, or Students in longer multi-period programs) to keep one physical or digital card for as long as they are associated with the institution, instead of receiving a new one every academic period.
• Cards are used for mobile wallet passes, and the institution wants to avoid disrupting or reissuing that pass every time an academic period changes.
• The cost or logistics of reprinting and redistributing physical cards every period is a concern the institution wants to reduce.
• The card’s design and printed information do not depend on the academic period (for example, it does not show the current grade, class, or term), so there is no practical need to reissue it each time.

When to Disable

• The institution’s card design includes information that changes per period (for example, a Student’s current grade, class, or academic year), so producing a fresh card each period is intentional and expected.
• The institution wants cards to automatically expire at the end of each academic period as a renewal or security control, in combination with the Default expiration date setting – for example, to ensure only currently enrolled Students can use their card for benefits or access.
• The institution’s normal process already reissues cards every period as part of how cards are physically distributed, so carrying a card over between periods would not match daily operations.

Notes

K-12 versus Higher Education Mode

This setting behaves identically whether the institution is running in K-12 mode or in Higher Education mode (controlled by the Higher Education customization setting). There is no functional difference in which entity types can be selected, or in how cross period card recognition and expiration work, between the two modes.

The only difference a user may notice is terminology and typical usage. When Higher Education mode is enabled, ‘Teachers’ is displayed using the institution’s configured term for that role (for example, ‘Lecturers’) – this is a labeling difference only and does not change how the setting behaves. In practice, Higher Education institutions – where a Student’s program commonly spans several academic periods under one Curriculum or degree – more often enable this setting for Students and Teachers/Lecturers, while K-12 institutions – where a card commonly needs to show the child’s current grade or class – more often leave Students disabled and enable it mainly for Employees. This is a usage tendency, not a restriction: any combination of entity types can be selected in either mode.

Prerequisites

• The relevant entity type’s ID/Code format setting must already be configured (see Related Settings), so the system knows how to generate and recognize that type’s card number before cross period retention can be relied on.
• If the institution also wants cards to be created automatically as people move between periods, the Auto-Create Cards Upon Entity Creation setting should be reviewed alongside this one, since the two settings work together to decide whether a new card is generated for a new period.
• Decide the institution’s expiration policy using the Default expiration date setting before enabling cross period cards, since enabling this setting exempts the selected entity types from any automatic period-end expiration.

Related Settings

• Auto-Create Cards Upon Entity Creation/AutoCreateCardsUponEntityCreation (Configuration > Main Settings > General Settings > Basic Customization tab > Card Settings section) – decides whether a new card is generated automatically when a person is created or moves into a new period; works directly together with this setting to decide whether a new card is created for a new period.
• Set ID/Code type to be used in Student cards/FormatStudentIdCards (same path) – defines how a _Student_ card’s identifying number is generated.
• Set ID/Code type to be used in Teacher cards/FormatTeacherIdCards (same path) – same purpose, for Teachers.
• Set ID/Code type to be used in Employee cards/FormatEmployeeIdCards (same path) – same purpose, for Employees.
• Set ID/Code type to be used in Relative cards/FormatRelativeIdCards (same path) – same purpose, for Relatives.
• Default expiration date/DefaultCardExpirationDate (same path) – determines whether cards expire automatically at the end of the academic period or never expire; this setting overrides that automatic period-end expiration for the entity types selected here.
• Enable QR code for benefits/EnableQRCodeForCardsBenefits (same path) – adds an extra QR code to cards used for verifying eligibility for benefits, which continues to work on cross period cards.
• Relative type of connections enabled for card creation/RelativeTypeEnabledForCardCreation (same path) – determines which relationship types (Parent, Guardian) qualify for a Relative card, which in turn can be kept across periods if Relatives is enabled here.