DOA Tables (Delegation of Authority)

A DOA (Delegation of Authority) table decides who a task goes to based on the data in each request — instead of hardcoding a single approver on a node. For example: route a travel request to a different approver depending on the department and amount, with higher amounts escalating to senior management.

You define the rules once as a table, then point an Approval or Input node at it. At runtime the workflow looks up the request's data, finds the matching row, and assigns the task to the people listed in that row.

📒

Key terms

  • Definition — the table's name, the application it belongs to, the default (fallback) assignee used when no row matches, and any table-level escalation levels.
  • Columns — the table's schema. Each column maps to a piece of request data (a data-center path such as forms.travel_request.amount), a display name, a data type, and a matching operator.
  • Rows — the actual rules. Each row holds the values to match against, the assignees to use when it matches, and optional row-level escalation overrides.

How matching works

When a node uses DOA, the engine resolves the assignee at runtime:

  1. It gathers the request's current data (form values, initiator details, global constants, etc.).
  2. It goes through the rows in order (top to bottom).
  3. For a row to match, every column condition must be satisfied — each column's operator is applied between the request's value and the row's value.
  4. The first row where all conditions match wins. Its assignees (and any escalation overrides) are used.
  5. If no row matches, the table's default assignee is used.
📘

Operators & dynamic values

  • Columns support operators including Equals, Not equals, Contains, In, Not in, and the numeric/date comparisons >, , <, — so you can match exact values, ranges, or membership in a list.
  • A row value can reference live data using {{...}} (for example, {USER.DEPARTMENT}), so the table can match against the initiator's own attributes rather than a fixed value.

Use a DOA table in a workflow

  1. In the Approval or Input node, set the assignment type to DOA and select the DOA table.
  2. At runtime, the engine resolves the assignee from the matching row.
  3. If the matched row defines escalation (SLA hours + escalation assignees), those override the node-level and table-level escalation settings for that request.

Create and manage DOA tables

DOA tables are managed in the admin / data area of Workflows Studio, scoped to a specific application:

  1. Create the table — give it a name, choose the application, and set a default assignee as a fallback.
  2. Add columns — for each piece of data you want to match on, add a column with its data-center field, a header name, a data type, and a matching operator.
  3. Add rows — enter the values to match and the assignee(s) for each rule. Rows are evaluated top-to-bottom, so order more specific rules above general ones.

Bulk-manage with a spreadsheet

For large tables, use Excel import/export rather than editing row by row:

  1. Export the table to get an XLSX template. Each field has a ..._Label column (what users see) and a ..._Value column (the value used for matching).
  2. Fill it in. A single rule can span multiple spreadsheet rows (for multiple values or multiple assignees); the New_Row column marked "Yes" indicates the start of a new rule. Use {{...}} in a value to match dynamically.
  3. Upload & verify — the file is validated (columns exist, users are valid) and any errors are reported.
  4. Commit — apply the verified data. Choose to replace the whole table or append to it.
📘

Test before you rely on it

Use the Test assignment option to check which row a real request would match: provide a request (reference) and the node, and it returns the matched row and the resulting assignees — handy when a task went to the wrong person.

📒

Good to know

  • Permissions: editing a DOA table requires edit access to its application (RBAC); agents only see DOA tables for applications they're authorized to manage.
  • Portability: DOA tables travel with the workflow — they're deep-copied when you clone an app and remapped during migration (with optional name prefixing like UAT_).
  • Global constants can be used as parameters in rows; see Global Constants.