Docs/Infohub (Flow)/Templates Across Calendars
Infohub (Flow)How-to

Templates Across Calendars

One template, instances on different time schemes — the mapping rules, what breaks, and the pattern that works.

Updated 15 Oct 2026Infohub Docs

The hardest recurring template problem is not structural — it is the calendar. A template is authored against one time scheme; real sites run different production days, different shifts, sometimes deliberately different calendars per operation. This article covers how calendar mapping behaves and the pattern that survives it.

The core rule#

Every measure in a template is attached to a time scheme — the one the template author used. When the template is instantiated or updated somewhere else, those attachments must resolve to time schemes in the destination.

Resolution is by mapping: at import/instantiation, incoming time-scheme references are mapped onto destination time schemes, name matching being the default. That yields the three situations that generate tickets:

  1. Same name both sides — maps silently and correctly. This is why the seeded Production scheme is a blessing when everyone keeps it and a trap when sites redefine it differently.
  2. No match — the operation prompts for a mapping (interactive) or fails/creates (scripted). An unnoticed "create" gives the site a second calendar it never wanted.
  3. Wrong match — the worst case: the site's Production has a 6-hour offset, the template's Production starts at midnight, the names match, and every daily figure lands six hours askew with no error anywhere.
Important

A name match is not a semantics match. The mapping machinery matches calendars by name; it cannot know that two schemes called Production disagree about when a day starts. Before templating across sites, compare the offsets, not the names.

What breaks in practice#

Update after re-mapping. Changing an instance's calendar by exporting a template, re-importing it mapped to a new calendar, and then updating from the template server again is fragile: the next update re-applies the template's calendar association, and the instance either errors ("key not present" family) or reverts. A re-mapping done at import time is not a durable per-instance override.

Shift patterns embedded in the template. A template whose measures include Shiftly intervals bakes in an assumption that the destination's shift scheme exists and matches. A site on 2×12 receiving a template authored on 3×8 has valid shifts, valid measures, and reconciliation that never adds up.

Refresh triggers and limits carry time-scheme references too. A calendar mismatch surfaces there as well — a limit whose ranges live on a scheme the site mapped away, a refresh trigger pinned to the wrong scheme. When a template lands and some of it misbehaves, list everything that references a time scheme.

Mixed calendars in one measure collection. A collection calc that gathers measures across instances on different calendars fails with a calendar-mismatch error — the collection's members must share a scheme.

The pattern that works#

One canonical scheme name, defined per site. The template references exactly one time scheme — call it Production. Every site defines its own Production with its own offsets (06:00 day here, 00:00 there, its own shifts). The name maps automatically; the semantics are the site's own. This is the shape to aim for, and it works because everything in the template is relative to the calendar rather than to clock times.

What it requires:

  • The template must never hard-code clock times (in expressions, use Period.StartLocal-relative logic, never 06:00).
  • Every site defines Production before deriving or instantiating, so nothing auto-creates.
  • Shift-interval content is only templated if every receiving site has a shift scheme — the pattern differing is fine; its absence is not.

Where sites genuinely need different calendars for different areas (one plant, two operations on different days): use two schemes with two distinct names, template each area against its scheme, and instantiate area-by-area. Do not try to make one template serve both calendars by re-mapping — that is the fragile path above.

Where a site must change calendar later (a shift-pattern change): treat it as a calendar change, not a template operation — see the live-change guidance in Interval Types and Time Schemes — and expect to update the template linkage afterwards, verifying instances still receive updates.

Recovering from a wrong mapping#

When an update has already gone through against the wrong default calendar:

  1. Stop updating — every further update deepens the wrong association.
  2. Identify the affected measures: everything whose measure-time-scheme rows point at the unintended scheme.
  3. Fix the association back to the intended scheme — on small scopes, per measure in Config; at scale, this is a support-assisted repair, because values live against the periods of the scheme they were calculated on.
  4. Recalculate the affected range on the corrected scheme.
  5. Delete the unwanted scheme only when nothing references it — the delete will refuse (or hang on dependencies) while references remain.

The honest cost statement: recovering from a wrong calendar mapping is far more expensive than the five minutes it takes to compare scheme definitions before instantiating. Make the comparison part of the site-onboarding checklist.

See also#

esc
↑↓ navigate · ↵ open · ⌘K anywhere