# 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](/apis/workflow/pool). ## Prerequisites - Treasure AI account administrator permissions. - A [Master API key](/products/my-settings/getting-your-api-keys). - At least one custom pool created with the steps in [Managing pools](/products/customer-data-platform/data-workbench/workflows/pool/managing-pools). - The Treasure Workflow API base URL for your region. See [Endpoints](/apis/endpoints/endpoints) for the full list. The examples on this page use the US endpoint, `https://api-workflow.treasuredata.com`. ## How rule evaluation works 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. Priority is unique Two rules in the same account cannot share the same priority value. Priority must be between 1 and 10000. ## Condition types A rule has one or two conditions. The supported condition types are listed below. ### project_name Matches when the attempt's project name satisfies the operator against any of the listed values. ```json { "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`. ### workflow_name Matches when the attempt's workflow name satisfies the operator against any of the listed values. ```json { "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`. ### workflow_type 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`. ```json { "type": "workflow_type", "values": ["audience", "customer_journey"] } ``` The supported workflow types are: | Value | Description | | --- | --- | | `ab_test` | A/B test workflows. | | `audience` | Audience workflows. | | `customer_journey` | Journey workflows. | | `predictive_scoring` | Predictive scoring workflows. | | `realtime` | Real-time 2.0 workflows. | | `segment_insight` | Segment insight workflows. | | `syndication` | Activation workflows. | ### invocation_type 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`. ```json { "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`. ## Create a rule ```shell curl -X POST \ -H 'Authorization: TD1 ' \ -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 ``` ## List rules ```shell curl -H 'Authorization: TD1 ' \ https://api-workflow.treasuredata.com/api/pool_rules ``` ## Get a rule ```shell curl -H 'Authorization: TD1 ' \ https://api-workflow.treasuredata.com/api/pool_rules/ ``` ## Update a rule ```shell curl -X PATCH \ -H 'Authorization: TD1 ' \ -H 'Content-Type: application/json' \ -d '{ "conditions": [ {"type": "project_name", "operator": "starts_with", "values": ["jp_", "kr_"]} ] }' \ https://api-workflow.treasuredata.com/api/pool_rules/ ``` ## Delete a rule ```shell curl -X DELETE \ -H 'Authorization: TD1 ' \ https://api-workflow.treasuredata.com/api/pool_rules/ ``` ## Worked example Suppose an account has these three rules: ```json // 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](/products/control-panel/security/auditlogs/premium-audit-log-events) for the event names and the operations they cover. ## Next step Once rules are in place, review [attempt queueing](/products/customer-data-platform/data-workbench/workflows/pool/attempt-queueing) to understand what happens when a pool is full.