Link variables

Forms and configurationDashboardproperties.link_variables{lt:name}{lt:me}default_pins

One pinned link serves every station: a role declares a variable, each device binds its value, and the link resolves at render time.

The situation

Four facilities share one packing role. Each floor tablet should open on its own facility’s queue, from the same pinned link, without per-device configuration in the database.

The recipe

Declare the variable on the role and reference it as the entire value of a facet:

roles: [{
  role: 'packing',
  properties: {
    link_variables: [{ name: 'facility', label: 'Facility', default: 'main' }],
  },
  default_pins: [
    { label: 'My facility',
      url: '/escalations/available?role=packing&facets={"facility":"{lt:facility}"}&status=available',
      badge: true },
    { label: 'My recent work',
      url: '/escalations/available?status=resolved&facets={"resolved_by":"{lt:me}"}&orderBy=[{"field":"resolved_at","direction":"desc"}]' },
  ],
}],

Members bind the value once from the user menu (“Link variables”). Resolution per variable: the device’s bound value, then the declared default, then the facet is dropped. {lt:me} is built in and reads the person acting: the badged person while a grant is live, the signed-in user otherwise.

The guarantee

Substitution happens at render time, so every link in the page is already concrete, and an unbound variable means no filter, never an empty-string match. Bindings live in device storage, so a shared workstation keeps its scope across reloads and account switches. Link variables are a view convenience: read scope still governs what any query returns. See Faceted routing.

Forms and configuration