Conditional Visibility

Conditions control when attributes, relations, and user relations are visible or editable. They enable role-based and state-based UI customization — showing different fields to different users depending on workflow state.

Three Condition Scopes

Conditions apply to three different asset types, each controlling visibility in a different part of the object detail page.

Scope	Controls	Applied to
Attribute conditions	Which attributes appear and whether they are editable	attributeTypes on an objectType definition
User relation type conditions	Which ownership roles (owner, steward) appear	userRelationTypes on an objectType definition
Relation type conditions	Which relations are visible in the relations panel	relationTypes referenced by an objectType

Each scope uses the same condition model — a combination of userRelationTypeKey and workflowStateKey that determines visibility and editability.

Condition Properties

Every condition evaluates against two context values: the current user’s role on the object and the object’s workflow state.

Property	Type	Purpose
objectTypeKey	string	Which object type this condition applies to (standalone conditions only)
userRelationTypeKey	string	The user role that triggers this condition. Matches the current user’s assigned role on the object.
workflowStateKey	string	The workflow state that triggers this condition. Matches the object’s current state.
editable	boolean	Whether the field is editable when the condition matches
visible	boolean	Whether the field is visible when the condition matches

Both editable and visible are independent. A field can be visible but not editable (read-only display) or editable and visible (full access). Setting visible: false hides the field entirely — editable has no effect when the field is hidden.

Inline Conditions

Inline conditions are defined directly on attribute types or user relation types within the object type definition. This is the most common approach for simple per-objectType rules.

{
  "key": "business_term",
  "attributeTypes": [
    {
      "key": "core#description",
      "conditions": [
        {
          "userRelationTypeKey": "core_business_owner",
          "workflowStateKey": "draft",
          "editable": true,
          "visible": true
        },
        {
          "userRelationTypeKey": "core_steward",
          "editable": true,
          "visible": true
        }
      ]
    }
  ]
}

This configuration makes the description attribute:

• Visible and editable to business owners, but only when the object is in draft state
• Visible and editable to stewards in any workflow state
• Hidden from all other users in all states

Standalone Conditions

Standalone conditions are separate package assets that apply across multiple object types. Three asset types exist:

Asset type	Controls
attributeTypeObjectConditions	Attribute visibility and editability
userRelationTypeObjectConditions	User relation type visibility
relationTypeObjectConditions	Relation type visibility

A standalone attribute condition:

{
  "attributeTypeObjectConditions": [
    {
      "attributeTypeKey": "cust_technical_id",
      "objectTypeKey": "business_term",
      "conditions": [
        {
          "userRelationTypeKey": "core_steward",
          "editable": false,
          "visible": true
        }
      ]
    },
    {
      "attributeTypeKey": "cust_technical_id",
      "objectTypeKey": "business_domain",
      "conditions": [
        {
          "userRelationTypeKey": "core_steward",
          "editable": false,
          "visible": true
        }
      ]
    }
  ]
}

This makes the cust_technical_id attribute visible (but read-only) to stewards on both business terms and business domains. Without standalone conditions, the same condition block would need to be duplicated in each object type definition.

Evaluation Logic

AND Within a Single Condition

Both userRelationTypeKey AND workflowStateKey must match for the condition to apply. A condition specifying core_business_owner and draft only activates when the current user is a business owner AND the object is in draft state.

Optional Keys

If only one key is specified, the other is treated as “any”:

Specified	Omitted	Behavior
userRelationTypeKey only	workflowStateKey	Applies to the specified role in any workflow state
workflowStateKey only	userRelationTypeKey	Applies to any user in the specified state
Neither specified	Both	Condition always matches (equivalent to no condition)

OR Across Multiple Conditions

When multiple conditions exist on the same attribute, OR logic applies. If any condition grants visibility or editability, the field is visible or editable.

Given these conditions on a description attribute:

{
  "conditions": [
    { "userRelationTypeKey": "core_business_owner", "workflowStateKey": "draft", "editable": true, "visible": true },
    { "userRelationTypeKey": "core_steward", "editable": true, "visible": true },
    { "workflowStateKey": "approved", "editable": false, "visible": true }
  ]
}

The description is visible to:

• Business owners in draft state (editable)
• Stewards in any state (editable)
• Any user when the object is approved (read-only)

A steward viewing an approved object matches both condition 2 and condition 3. Since condition 2 grants editable: true, the field is editable — the most permissive grant wins.

No Conditions = Full Access

An attribute, user relation type, or relation type without any conditions is visible and editable by all users in all states. Conditions restrict the default behavior — they do not grant it.

This means adding the first condition to a previously unconditioned field restricts access. Users who previously had full access may lose visibility or editability.

Inline vs. Standalone: When to Use Which

Scenario	Approach
Single object type with unique visibility rules	Inline conditions on the objectType
Same condition applies to 3+ object types	Standalone condition asset
Patch package modifying another package’s visibility	Standalone condition asset (cannot modify inline conditions in another package)
Rapid prototyping and testing	Inline conditions (easier to read in one file)

Standalone conditions from a patch package merge with existing inline conditions using OR logic. A patch package can grant additional visibility but cannot revoke visibility granted by inline conditions in the base package.

User Relation Type Conditions

User relation types on an object type can also carry conditions, controlling when the role assignment panel is visible.

{
  "key": "business_term",
  "objectUserRelationTypes": [
    {
      "key": "core_business_owner",
      "conditions": [
        {
          "workflowStateKey": "draft",
          "visible": true,
          "editable": true
        },
        {
          "workflowStateKey": "approved",
          "visible": true,
          "editable": false
        }
      ]
    }
  ]
}

In draft state, the business owner assignment panel is visible and the role can be changed. In approved state, the panel is visible but the assignment is locked.

Relation Type Conditions

Relation types between object types support the same condition model. This controls when the relation panel shows specific relation types.

{
  "relationTypeObjectConditions": [
    {
      "relationTypeKey": "core#isRelatedTo",
      "objectTypeKey": "business_term",
      "conditions": [
        {
          "userRelationTypeKey": "core_steward",
          "visible": true,
          "editable": true
        }
      ]
    }
  ]
}

The “is related to” relation panel on business terms is visible and editable only to stewards. Other users do not see this relation type on the object detail page.

Gotchas