Managing Pool Rules

A pool rule decides which pool an attempt is assigned to when it is created. Each rule has a priority, one or two conditions, and the ID of the pool that matching attempts go to. For the full request and response schema of each endpoint, see the Treasure Workflow API reference.

• Treasure AI account administrator permissions.
• A Master API key.
• At least one custom pool created with the steps in Managing pools.
• The Treasure Workflow API base URL for your region. See Endpoints for the full list. The examples on this page use the US endpoint, https://api-workflow.treasuredata.com.

When an attempt is created, Treasure Workflow evaluates the account's rules one by one in priority order, from the lowest value to the highest. All conditions within a rule must match for the rule itself to match. The first matching rule wins, and the attempt is assigned to that rule's pool. If no rule matches, the attempt is assigned to the default pool.

Once an attempt is assigned, the assignment never changes, even if you update the rules afterwards.

A rule has one or two conditions. The supported condition types are listed below.

Matches when the attempt's project name satisfies the operator against any of the listed values.

{
  "type": "project_name",
  "operator": "starts_with",
  "values": ["jp_", "kr_"]
}

The only supported operator is starts_with, which returns true when the project name begins with any value in values.

Matches when the attempt's workflow name satisfies the operator against any of the listed values.

{
  "type": "workflow_name",
  "operator": "starts_with",
  "values": ["behavior_", "import_"]
}

The only supported operator is starts_with, which returns true when the workflow name begins with any value in values.

Matches when the attempt's workflow type is one of the listed system workflow types. The workflow_type condition does not take an operator field. The condition is met when the attempt's workflow type equals any value in values.

{
  "type": "workflow_type",
  "values": ["audience", "customer_journey"]
}

The supported workflow types are:

Matches when the attempt's invocation type is one of the listed values. The invocation_type condition does not take an operator field. The condition is met when the attempt's invocation type equals any value in values.

{
  "type": "invocation_type",
  "values": ["scheduled"]
}

The supported values are:

• scheduled: the attempt was started by a workflow schedule.
• on_demand: the attempt was started by anything other than a schedule (for example, an API call from a client or from Data Workbench, or a backfill).

Invocation type is inherited through require> and workflow triggers. When attempt A is invoked by a schedule, A starts attempt B with require>, and B starts attempt C through a workflow trigger, all three attempts have invocation type scheduled.

curl -X POST \
    -H 'Authorization: TD1 <api_key>' \
    -H 'Content-Type: application/json' \
    -d '{
      "priority": 30,
      "poolId": "2",
      "conditions": [
        {"type": "project_name", "operator": "starts_with", "values": ["jp_"]}
      ]
    }' \
    https://api-workflow.treasuredata.com/api/pool_rules

curl -H 'Authorization: TD1 <api_key>' \
    https://api-workflow.treasuredata.com/api/pool_rules

curl -H 'Authorization: TD1 <api_key>' \
    https://api-workflow.treasuredata.com/api/pool_rules/<pool_rule_id>

curl -X PATCH \
    -H 'Authorization: TD1 <api_key>' \
    -H 'Content-Type: application/json' \
    -d '{
      "conditions": [
        {"type": "project_name", "operator": "starts_with", "values": ["jp_", "kr_"]}
      ]
    }' \
    https://api-workflow.treasuredata.com/api/pool_rules/<pool_rule_id>

curl -X DELETE \
    -H 'Authorization: TD1 <api_key>' \
    https://api-workflow.treasuredata.com/api/pool_rules/<pool_rule_id>

Suppose an account has these three rules:

// Rule A
{
  "priority": 10,
  "poolId": "34",
  "conditions": [
    {"type": "project_name", "operator": "starts_with", "values": ["jp_", "kr_"]}
  ]
}

// Rule B
{
  "priority": 20,
  "poolId": "41",
  "conditions": [
    {"type": "project_name", "operator": "starts_with", "values": ["eu_"]},
    {"type": "workflow_name", "operator": "starts_with", "values": ["campaign_"]}
  ]
}

// Rule C
{
  "priority": 30,
  "poolId": "59",
  "conditions": [
    {"type": "project_name", "operator": "starts_with", "values": ["us_"]}
  ]
}

Treasure Workflow evaluates the rules in this order:

1. Rule A matches when the project name starts with jp_ or kr_. Matching attempts go to pool 34.
2. Rule B matches when the project name starts with eu_ and the workflow name starts with campaign_. Matching attempts go to pool 41.
3. Rule C matches when the project name starts with us_. Matching attempts go to pool 59.
4. If none of the rules match, the attempt goes to the default pool.

Rule management actions are recorded as Premium Audit Log events. See Premium Audit Log Events for the event names and the operations they cover.

Once rules are in place, review attempt queueing to understand what happens when a pool is full.