Messagevisor

Building blocks

Attributes

Attributes describe the runtime context fields that Messagevisor conditions can read. They give your conditional logic a shared schema instead of leaving it as unstructured ad hoc data.

What attributes are for

Attributes help Messagevisor:

  • lint segment and override conditions (catching wrong attribute names and type mismatches early)
  • explain context usage in the Catalog
  • keep conditional logic consistent across definitions
  • make runtime context easier for humans to reason about

Attribute keys

Like messages, attribute keys come from file paths relative to the attributes/ directory:

Example
attributes/plan.yml         -> plan
attributes/country.yml      -> country

Description

Attribute files can have a description field to provide a human-readable description of the attribute. This is used in the Catalog and other UIs.

attributes/country.yml
description: Country attribute

Type

The type field is required for every attribute file. It defines the kind of value allowed for this attribute. The following examples show canonical combinations of type and relevant schema fields:

string

attributes/country.yml
description: Country code
type: string
# below properties are optional
enum:
  - US
  - GB
  - NL
minLength: 2
maxLength: 2
pattern: "^[A-Z]{2}$"

boolean

attributes/email-verified.yml
description: Whether user email is verified
type: boolean

integer

attributes/age.yml
description: User age in years
type: integer
# below properties are optional
minimum: 0
maximum: 120

double

attributes/score.yml
description: User's high-precision score
type: double
# below properties are optional
minimum: 0
maximum: 100.0

date

attributes/birthdate.yml
description: User birthdate
type: date

object

attributes/address.yml
description: Postal address
type: object
# below properties are optional
required:
  - street
  - city
properties:
  street:
    type: string
    minLength: 1
  city:
    type: string
  postalCode:
    type: string
    pattern: "^[A-Z0-9]{4,10}$"
additionalProperties: false

array

attributes/permissions.yml
description: User permission list
type: array
items:
  type: string
  enum: # optional
    - read
    - write
    - admin
# below properties are optional
minItems: 1
maxItems: 5
uniqueItems: true

Archived

When set to true it removes an attribute from normal lint and list operations:

attributes/plan-pro.yml
description: Pro plan users
archived: true

Promotable

When set to false it prevents this attribute from being copied during promotion:

attributes/plan-pro.yml
description: Pro plan users
type: string
promotable: false

Using attributes in conditions

Attributes are referenced by key in segment conditions and message override conditions. See Conditions for the full operator and composition reference.

segments/plan-pro.yml
description: Pro plan users
conditions:
  - attribute: plan
    operator: equals
    value: pro
segments/adult.yml
description: Adult users
conditions:
  - attribute: age
    operator: greaterThanOrEquals
    value: 18

For nested object attributes, use dot notation to reference sub-fields:

segments/account-nl.yml
description: Dutch account users
conditions:
  - attribute: account.country
    operator: equals
    value: NL

Why this matters for conditions

Most conditional authoring pain comes from context mismatch:

  • wrong attribute name
  • wrong value type
  • one team thinks a field is a string while another uses a boolean

Attributes make those mistakes easier to catch during authoring instead of after runtime behavior drifts.

Attributes and tests

Attribute behavior is usually tested indirectly through:

  • segment tests (which test conditions that use attributes)
  • message tests and target evaluation tests that pass context

That is usually enough. You do not typically need attribute-only tests.

Examples

Simple string attribute with enum values:

attributes/platform.yml
description: Runtime platform
type: string
# optional: list of allowed values
enum:
  - web
  - ios
  - android

Integer attribute with minimum:

attributes/age.yml
description: User age in years
type: integer
minimum: 0

String attribute with enum-restricted values:

attributes/plan.yml
description: Subscription plan
type: string
enum:
  - free
  - pro
  - enterprise

Object attribute with nested properties:

attributes/account.yml
description: User account metadata
type: object
properties:
  country:
    type: string
  locale:
    type: string

Array attribute:

attributes/permissions.yml
description: User permission list
type: array
items:
  type: string
  enum:
    - read
    - write
    - admin

Edge cases and behavior notes

Describe vs populate

Attributes describe context, they do not populate it.

The schema tells Messagevisor what runtime context is supposed to look like. Your application, tests, or CLI inputs still supply the actual values using the SDK.

Simplicity over complexity

If a condition can be expressed clearly with a few simple attributes, that is usually easier to review than one large nested object with lots of path-dependent logic.

For documentation purposes

At runtime, the SDK does not validate context against attribute schemas. Attributes are purely authoring-time documentation and linting infrastructure.

Previous
Messages
Next
Segments