Troop overrides

A troop is where you set customization once for the whole team. Rather than configuring every site key by hand, you author a baseline on the troop, and every key in it inherits the result. A key can then override just the exceptions it needs. This is the troop's main day-to-day value beyond holding keys: one place to set the brand, many keys that follow it.

Authoring troop-wide overrides needs the manage permission (they are troop administration). Overriding a single site key, by contrast, needs only edit on that key.

What a troop can override

• Game customization. Set a game's language, skin, and configuration on the troop, and every key that runs that game inherits them. See the game customization overview.
• White-label (Apex). Set the widget shell's wording, colors, brand mark, and links on the troop, and every key's widget renders them.

Both are authored from the troop's own settings, the same editors a site key uses, just one level up.

How inheritance resolves

Overrides resolve most-specific-wins, per value:

A site-key value beats the troop value, which beats the bundled default, computed one value at a time. So a site key can change a single color while inheriting everything else from the troop, which in turn inherits from the game. The practical pattern: set the brand once on the troop, then override only the genuine exceptions on individual keys.

This is the same resolution a single key uses, described in full under game customization scopes; the troop is simply the baseline layer in it.

Plan tiers

The override axes unlock at the same plans they do for a single key: game configuration on every paid plan, game language and skin from Alpha, and white-labeling the shell on Apex. The game customization tier table is the reference.

See also

• Game customization: the per-axis editors and the scope model.
• White-label the widget: the Apex shell overrides a troop can set.
• Permissions and scope: the manage and edit permissions this needs.