Core Concepts & Data Flow
A quick mental model of ID Studio: what an ID and a tag are, how templates are versioned, the states a card moves through, and how a card is rendered and verified.
Employee ID vs. tag serial
The business identifier printed on the card (e.g. ACME-2026-00421). Stored as the employee's Job ID and reused for every card that employee is issued. One per employee.
A unique, opaque per-card code (e.g. TAG-A1F4-8C20). Every generated card gets its own serial — a replacement reuses the employee ID but gets a new serial. The QR encodes the serial, never personal data.
The ID-format token engine
A format is a pattern of literal text and tokens. The rules the engine enforces:
- Exactly one sequence token (
{SEQ}or padded{SEQ:4}…{SEQ:10}). - Tokens:
{COMPANY} {YEAR} {YY} {MONTH} {DEPT} {LOC} {SEQ} {JOBID}. - The generated ID must fit the Job ID column; the settings screen previews it and checks for length and collisions.
- The reset policy partitions the counter: never = one running counter; yearly = a fresh counter per year; monthly = per month.
Why allocation can't collide
Templates & versions
A template is a card design; its layout is stored as a validated JSON document (positions are percentages of the card, so it scales to full print resolution). Key ideas:
- A template has a status: draft published archived.
- Published versions are immutable. Editing a published template starts a new draft version — the published layout that cards were generated from never changes.
- Generation always uses a template's published version, so a card is a faithful record of the design at the time it was made.
- The layout is a declarative document, validated and sanitised on the server — never runnable HTML/JS.
The tag lifecycle
Every generated card (a tag) moves through these states:
| Status | Meaning |
|---|---|
| generated | Rendered and recorded; not yet printed or handed over. |
| printed | Marked as physically printed. |
| issued | Handed to the employee. |
| expired | Past its validity date (shown automatically; the daily job also sets it). |
| revoked | Invalidated with a required reason (lost/compromised). |
| replaced | Superseded by a newer card; the old and new cards link to each other. |
How a card is produced
Published template (JSON layout) + Employee merge data
│
▼
Server renderer (draws each element at its % position)
│
├──▶ Front PNG ├──▶ Back PNG ├──▶ CR80 PDF (85.6 × 54 mm)
▼
generated_tags row (unique serial · data snapshot · validity · file refs)
│
▼
Registry ──▶ print / issue / revoke / replace ──▶ QR verificationThe data snapshot stored on the tag is the exact field data used at generation time, so a card's record never changes even if the employee's details later do.
Verification
A card's QR encodes a link like …/id/verify/<company>/<serial>. Scanning it
opens a public page that reports only a status — valid, expired, revoked, superseded or
unknown — and never discloses employee details.