AireFlow Docs

Appearance

Task Owner ​

The owner and owner type fields represents the user or entity who "owns" a task at a given point in the workflow. AireFlow itself does not rely on either property for anything, but other systems such as AireFrame can use it.

owner and owner type are optional properties.

How it’s set ​

The owner can be assigned or updated through several mechanisms:

  1. Workflow definition

    • An owner can be configured for each task in the workflow builder.
    • Supports dynamic expressions (e.g. XPath or Liquid), similar to other configurable fields like name or assignee.

  2. Event propagation

    • The owner is automatically included in any events emitted by a task.
    • When a task is triggered by an event from another task:
      • The owner is set from the event payload by default
      • If the task definition specifies an XPath/Liquid expression for owner, that expression takes precedence over the owner from the event

  3. API updates

    • The owner can be modified at runtime via the PATCH API or via a Mutation.

  4. From AireFrame

    • When a task is updated via AireFrame, the owner and owner type will automatically be set to reflect the user who made the update.

Owner Type ​

When using the owner to refer to an AireFrame user, the owner type field should be used to keep track of the type of AireFrame user so the user can be rendered correctly. AireFrame supports the following owner types:

  • User - Looks up the ID against AireAuth and shows the user’s display name
  • Subject - Looks up the ID against AireFrame subjects and shows the primary field value
  • Subject Proxy - Looks up the ID against AireAuth and shows the user’s display name
  • External - Shows as [Id] (External)
  • Client Credentials - Shows as [Id] (System)
  • System - Shows as [Id]
  • Unknown - Shows as [Id]

Behavior and considerations ​

  • The owner and owner type fields are optional and mutable.
  • Ownership can be dynamically resolved at runtime using expressions.
  • Propagation through events ensures continuity of ownership across workflow steps.
  • Explicit configuration (XPath/Liquid) overrides inherited values from task events.
  • API updates can override previously set values at any point in the task lifecycle.

Example ​

  • Task A is defined with owner = User1
  • Task A emits an event with owner = User1
  • Task B is triggered by the event:
    • If no expression is defined → owner = User1 (inherited)
    • If owner is defined as an expression → evaluated result is used instead
  • Task B is later updated by User2 in AireFrame → owner = User2