Overview

The Auto-Create Cards Upon Entity Creation setting controls whether the system automatically generates an identification card (ID card) the moment a new person record is created in Classter, instead of requiring staff to create the card manually afterward.

An ID card in Classter is a printable 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 or access scanning where those are in use. This setting simply decides who gets one automatically the moment their record is created, and for whom staff must still create it by hand.

This setting can be turned on independently for four different types of people: _Students_, Teachers, Employees (Staff), and Relatives (Parents/Guardians). Any combination of these can be selected at the same time.

What This Setting Does

This setting is a multi-select list. The administrator chooses which of the following entity types should automatically receive an ID card as soon as a new record for that type is saved in the system:

• _Students_ – A new _Student_ record (for example, through admission, quick registration, or the parent portal ‘add a child’ option) automatically receives an ID card as soon as it is saved.
• _Teachers_ – A new _Teacher_ (Educator/Instructor) record automatically receives an ID card as soon as it is saved.
• Employees – A new Employee (Staff) contact record automatically receives an ID card as soon as it is saved.
• Relatives – A new Relative (Parent/Guardian) contact record automatically receives an ID card as soon as it is saved. This also applies when a Relative record is linked automatically while creating a _Student_ (see Business Logic / Behavior below).

If an entity type is not selected in this setting, records of that type are not affected: staff must create an ID card manually for that person afterward, using the normal ‘create card’ option on their profile, if a card is needed at all.

By default, this setting is empty, meaning automatic card creation is switched off for all four entity types until an administrator explicitly turns it on.

Where It Is Used

This setting is checked automatically, in the background, at the exact moment one of the following actions is completed. Staff do not see or interact with this setting directly while performing these actions – they simply notice that a card already exists afterward, if the corresponding option is enabled:

• Creating a new _Student_ – through the standard _Student_ creation/admission form, the online quick admission (self-registration) form, or the parent portal option for a parent to register an additional child.
• Re-registering a returning _Student_ into a new academic period – if the _Student_ does not already have a card that carries over between periods (see the Cross Period Cards setting under Related Settings), a new card is created for the new period.
• Creating a new _Teacher_ record.
• Creating a new Employee (Staff) contact record.
• Creating a new Relative (Parent/Guardian) contact record, either directly or automatically alongside a _Student_ record (see Business Logic / Behavior).

This setting applies uniformly across the whole institution – it is not possible to enable automatic card creation 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 happens for an entity type unless it is explicitly selected in this setting. Leaving the list empty (the default) means no cards are created automatically for any entity type; staff must create them manually.
• Selecting Relatives creates a card for a Relative record the moment it is saved on its own, and also automatically creates a card for a _Student_’s linked parent(s)/guardian(s) right after that _Student_’s own card is created – but only for the relationship types (Parent and/or Guardian) that are separately allowed by the ‘Relative type of connections enabled for card creation’ setting. If that setting has no relationship types selected, no Relative cards are created automatically, even if Relatives is checked here.
• Each entity type has its own separate ID/Code format setting (see Related Settings) that defines how the identifying number printed or encoded on the card is generated (for example, based on the person’s internal code, registration number, or a running card number). If that format setting has not been configured for a given entity type, the system cannot generate the card automatically and will skip it, recording an error rather than creating a blank or invalid card.
• If a person already has a valid ID card and the staff member (or automated process) performing the action does not have rights to reissue cards, a duplicate card is not created.
• A dedicated Card Templates screen can optionally be used to design the visual layout of the printed card (logo, photo, and up to eight custom fields). This setting does not require a template to be configured – if none exists, the system still creates the card automatically using a simple default layout with a QR code.

Assumption (not directly confirmed in the setting’s own logic, but consistent with its purpose and naming): this setting exists to reduce manual administrative work for institutions that issue ID cards to most or all of a given group as a standard part of onboarding, so that staff do not need to remember to create a card separately every time a new _Student_, Teacher, Employee, or Relative is registered.

Example(s)

Example 1 – K-12 school, Students only

Northbridge Academy enables this setting for _Students_ only. A front-office administrator registers a new _Student_, Emma Carter, in Grade 4. As soon as the registration is saved, the system automatically creates Emma’s ID card in the background, using the school’s configured ID/Code format (for example, based on her internal student code). The administrator does not need to open a separate ‘create card’ screen – the card is ready to print immediately. Because Teachers, Employees, and Relatives are not selected in this setting, a new teacher hired the same week does not receive an automatic card and must have one created manually if needed.

Example 2 – Higher Education college, Students and Relatives

Summit College operates in Higher Education mode and enables this setting for both _Students_ and Relatives, while also configuring the ‘Relative type of connections enabled for card creation’ setting to include Parent connections. When admissions staff register a new _Student_, Daniel Osei, and link his father as a Parent contact during the same process, two things happen automatically: Daniel receives his own _Student_ ID card, and his father automatically receives a Relative ID card as well, without staff needing to create it separately. If Daniel’s mother is later added as a Guardian rather than a Parent connection, and Guardian connections are not included in the relationship setting, no automatic card is created for her – staff would need to create one manually if the college wants her to have a card too.

When to Use

When to Enable

• The institution issues ID cards to most or all _Students_, _Teachers_, Employees, or Relatives as a standard part of onboarding, and wants this to happen automatically rather than relying on staff to remember.
• The institution uses ID cards for daily operational purposes (identification, quick lookup, benefits verification, or attendance/access scanning where in use) and needs cards to exist as early as possible after a person joins.
• The institution wants parents/guardians to automatically receive their own card whenever their linked _Student_ is registered, to save a manual step for front-office staff.

When to Disable

• The institution does not use physical or digital ID cards at all, or only issues them to a small subset of people on request.
• Card issuing is a deliberate, separate administrative step at this institution (for example, cards are only produced once per year during a dedicated printing batch), so automatic creation at the moment of registration is not desired.
• The institution has not yet configured the ID/Code format setting(s) for the relevant entity types; enabling automatic creation before that configuration is in place will simply result in skipped cards and recorded errors rather than usable cards.

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 automatic card creation is triggered between the two modes.

The only difference a user may notice is terminology and typical usage: Higher Education institutions more commonly enable this for Employees and Relatives alongside _Students_, while K-12 institutions more commonly enable it primarily for _Students_ and Teachers. Labels shown on screen (for example, ‘_Student_’ or ‘Relative’) may also read differently depending on the institution’s configured terminology, without changing how the setting works.

Prerequisites

• The corresponding ID/Code format setting must be configured for each entity type being enabled here (see Related Settings below); otherwise automatic card creation for that entity type will be skipped.
• To have Relative cards created automatically alongside a _Student_’s card, the ‘Relative type of connections enabled for card creation’ setting must also include the relevant relationship type(s) (Parent and/or Guardian).
• A Card Template is optional. If the institution wants automatically created cards to follow a specific visual design (logo, photo, custom fields) rather than the default layout, the template should be configured in advance under the Card Templates screen.

Related Settings

• Set ID/Code type to be used in Student cards/FormatStudentIdCards (Configuration > Main Settings > General Settings > Basic Customization tab > Card Settings section) – defines how the _Student_ card’s identifying number is generated; required for automatic _Student_ card creation to succeed.
• 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.
• Relative type of connections enabled for card creation/RelativeTypeEnabledForCardCreation (same path) – determines which relationship types (Parent, Guardian) qualify for automatic Relative card creation.
• Enable Cross Period cards for the following entities/EnableCrossPeriodCardsForEntities (same path) – determines whether a person keeps the same card across academic periods, or receives a new card automatically each time they are re-registered into a new period.
• Default expiration date/DefaultCardExpirationDate (same path) – determines whether automatically created cards expire at the end of the academic period or never expire.
• Enable QR code for benefits/EnableQRCodeForCardsBenefits (same path) – adds an extra QR code to automatically created cards for verifying eligibility for benefits.