Timely models four distinct concepts that get confused easily because they all look like "metadata attached to a person or a shift." This page lays out what each one is for and where they touch.
The four axes at a glance
| Axis | Answers | Lives on | Many-per | Changes how often |
|---|---|---|---|---|
| Designation (role) | What's their job title? | employees.designation |
One per employee | Slowly (promotions) |
| Tags | What skills, certifications, or attributes? | employees ↔ org_tags |
Many per employee | Slowly (training) |
| Subjects | Who or what was the work FOR? | time_entries ↔ subjects |
Many per shift | Per shift |
| Punch fields | What KIND of work was it? | time_entries ↔ time_entry_field_values |
Many possible defs, one value per def | Per punch |
There's a fifth concept too, but it's narrow: schedule_days.designation_override lets you change an employee's effective role for a single shift (e.g., a Barista who's covering as Shift Lead today). That's per-shift role, not a new axis.
Why they're separate
Designation describes the worker. Tags describe what the worker can do. Subjects describe who or what the work is for. Punch fields describe what kind of work it actually was. These are four different questions with four different answer-spaces. Forcing them to share a schema or a UI control tangles them up later when reports and rules need to slice on each independently.
A quick gut-check: if a fact about someone or something would change at a different rate than another fact, they probably belong on different axes.
- A Barista (designation) is Closing-trained (tag) → both stable for months at a time
- A Barista works a shift for Customer A (subject) doing delivery prep (punch field) → both change shift-to-shift
- Mixing them = "we made Customer A a tag" → now your tag list is full of customer names and you can't filter "who's Closing-trained"
When you'd use each
Picking the right axis for a new requirement:
| If you want to… | Use this |
|---|---|
| Filter or group employees in the schedule editor | Tags |
| Require qualified employees for certain shifts | Tags (in schedule rules) |
| Pay or report by who the work was for | Subjects |
| Track which client/project/resident a shift covers | Subjects |
| Categorize the work itself (service code, cost code, billable matter) | Punch fields |
| Capture per-punch evidence or notes specific to a shift type | Punch fields |
| Display the worker's job title across the product | Designation |
| Temporarily override role for a single shift | designation_override on the shift |
Where they touch
Genuinely orthogonal most of the time. But there are three integration points worth knowing about because they show up in scheduling rules and exports:
Tag-gated subject assignment — A rule that requires an employee to have a specific tag before they can be scheduled with a specific subject. "Pediatric Hospital subject → require Pediatric Cert tag." Surfaces in the rules engine, not on the subjects page.
Subject-driven field defaults — A subject's metadata can declare default values for punch fields. "Subject John D. always uses service code T1019" — when you attach John to a shift, the next clock-in pre-fills service_code = T1019. The worker can override.
Field-tag validation — A rule that requires a tag when a specific field value is submitted. "If service_code = T2025 (BCBA-level), the employee must have the BCBA-Certified tag." Fires at punch time as a warning that lands in the timesheets review queue.
These aren't schema changes — they're rules layered on top of the existing axes. Each is opt-in per org.
Plan tiers
| Tier | Has |
|---|---|
| Free | Designation |
| Starter | + Tags |
| Pro | + Subjects, + Punch fields |
| Business+ | + Cross-axis rules (when shipped) |
Common modeling questions
"We have customers AND projects — can we have two subject types?"
Not yet. One subject label per org (configured under Settings → [your subjects page] → Rename label). If you genuinely need two distinct subject taxonomies — like a property-management company that tracks both Properties and Tenants — file an issue; multi-type subjects is on the v2.x roadmap.
"Should I make 'service code' a tag or a punch field?"
Punch field. Tags describe the worker; punch fields describe the work. A worker is BCBA Certified (tag) — they CAN deliver BCBA-level service. The punch records that on this particular shift, they DID deliver T2025 (field). The tag is stable; the field varies shift-to-shift.
"Should the same DSP supporting four residents create one entry or four?"
One. Multi-subject is the supported pattern — time_entry_subjects is a many-to-many. The single punch carries all four subjects; reports can slice by subject and divide hours evenly (that's how the QuickBooks export does it).
"Can I rename Subjects to something else?"
Yes. Settings → [subjects page] → Rename label. The rename is per-org and changes the noun across the product (sidebar, page titles, picker placeholders). The underlying table doesn't move. Common labels: Customer, Project, Member, Client, Matter, Property.
See also
- Job coding & subjects — the full setup walkthrough
- Timesheets — where the entries and field values surface
- Schedule rules — where the cross-axis integration lives when you build it