Contexts and Attributes

Context is the actor requesting flags

A context tells Zenmanage who or what is asking for a flag. That actor might be a user, organization, service, job runner, or another domain-specific type in your system. The stable identifier is what powers both targeting and percentage rollouts.

{
  "type": "organization",
  "identifier": "org_acme",
  "name": "Acme Corporation",
  "attributes": [
    { "key": "region", "values": [{ "value": "us-east" }] },
    { "key": "plan", "values": [{ "value": "enterprise" }] }
  ]
}
  

Required fields

• type: the actor category such as user, organization, or service.
• identifier: the stable unique identifier used for matching and bucketing.
• name: optional display text for human readability.

Attributes

Attributes are key-value lists used by attribute selectors. The current SDK data model treats every attribute as a key with one or more string values, so convert booleans, numbers, and enums into strings before you send them.

Examples include country, subscription plan, account tier, device type, or job role. Avoid sending attributes that you do not actively target.

Attributes are discovered from traffic

There is no schema to declare before you can target an attribute. Zenmanage builds the attribute vocabulary for each environment from the contexts it observes — an attribute and its values become available as suggestions in the rule builder only after contexts carrying that attribute have been seen in that environment.

This has two practical consequences. Send an attribute from your app before you try to target it — a brand-new attribute will not appear in suggestions until traffic delivers it. And because discovery is per environment, expect staging and production to offer different suggestions when their traffic differs; an attribute your staging tests never send will not show up there, even if production sees it constantly.