Operator guideEN

Activity Tag Rules / Create

Create flow for a new activity tag rule, including optional clone-from-existing behavior, transaction condition testing, and one-or-two-rule save behavior.

How to use this guide

Start with the main guide

Follow the explanation and examples first. Extra definitions and formulas are available below when you need them.

What this page does

Use this page to create a new activity-driven tag rule. Operators choose the triggering activity, configure one or two tag actions, optionally add transaction-oriented condition data, test that data against the estimator, and then save one stored rule or a pair.

Main workflow

  • Start with Rule Information: name, activity, and optional description.
  • Enable Add Tag, Remove Tag, or both.
  • Set priority and active state.
  • If the selected activity exposes conditions, add the required condition rows and test them before saving. This validates estimator matching, not live webhook enforcement.
  • Save the rule configuration. If both tag actions are enabled, the form submits two creates.

Validation Rules

  • Rule Name is required.
  • Activity is required.
  • Rule Priority is required and must be 0 or higher.
  • At least one tag configuration must be enabled.
  • If Add Tag is enabled, Tag Name to Add is required.
  • If Remove Tag is enabled, Tag Name to Remove is required.

Conditions

Conditions are only shown for the supported transaction activity codes. The current condition types include transaction status, sequence, amount, country, payment method, payment provider, withdrawal-without-deposit, documents submitted, KYC verification status, and ID verification status.

Test Conditions estimates matching users from the current activity and condition payload. It does not save the rule and does not add or remove tags. The estimator supports the listed form keys, but the live rule model currently evaluates a different legacy set: minCount, maxCount, minAmount, maxAmount, and timeFrame.

For Amount conditions, the labels are misleading: greaterThan includes equal values (>=) and lessThan includes equal values (<=). ID Verification Status is estimated from whether the user's document-label array is empty, not from a separate ID-verification status field.

Important caveats

  • When both Add Tag and Remove Tag are enabled, the save action sends two create requests concurrently.
  • The paired save is not verified as all-or-nothing. If one create succeeds and the other fails, operators should check the rules list before retrying.
  • The remove-tag rule gets a slightly lower priority than the entered value.
  • If this page is opened from Clone Rule, the page loads the source rule and can pre-fill scalar values with a new name ending in (Copy).
  • Clone mode has no dedicated loading, not-found, or read-error presentation. If the source read fails, the shared form can remain a blank create form; confirm the expected copied values before saving.
  • Clone condition rows are not reliably synchronized after the asynchronous source rule arrives. Verify every condition and re-enter missing rows before testing or saving the clone.
  • Conditions are not available for every activity. The page only enables them for the supported transaction activity codes.
  • Saved condition JSON is not proof of equivalent live filtering. Live tag mutation is performed by the signed activity webhook, whose model evaluator does not currently implement the form's condition keys.
  • The create screen does not provide a durable action-history confirmation. After saving, verify the expected stored rule or pair in the list before repeating a submission.

Form behavior, estimator behavior, clone prefill behavior, create paths, and the separate live webhook evaluator have been traced.

More details

Definitions and formulas

Open only the section you need. The relevant section opens automatically when you request help for a specific item on screen.

Calculations8 topicsOpen details

Clone prefill

Logic
When a clone source rule ID is present, the page mounts the shared form and loads that rule asynchronously., Scalar form values can reinitialize and the clone name is copied with `(Copy)` appended., Source rule IDs are removed from the create form payload so save creates new rules., The separate local condition-row array is initialized before asynchronous clone data is available and has no synchronization effect; cloned conditions can therefore be omitted from Test or Save., A failed clone read has no dedicated loading, not-found, or error state and can leave a blank create form.

Validation before save

Logic
Rule Name, Activity, and Priority are required., Priority must be at least `0`., At least one tag configuration must be enabled., Enabled Add Tag requires Tag Name to Add., Enabled Remove Tag requires Tag Name to Remove.

Condition availability

Logic
Conditions are only shown for the supported transaction activity codes., Non-transaction activities show an information message and save without condition rows., Add Condition creates a local row with default type `status`.

Condition payload build

Logic
Condition rows are converted into a keyed source conditions object., Empty condition values are omitted except for payment method, where an empty value can be intentionally sent., Amount conditions can carry an operator and value pair., Estimator amount operators map `greaterThan` to `>=`, `lessThan` to `<=`, and `equals` to `=`., Country, document, ID verification, and KYC conditions require user-row data during source estimate., Estimator ID Verification Status uses document-label array presence, the same predicate family as Documents Submitted, rather than a separate ID-verification status field., The same keys are not implemented by the current live model evaluator.

Test estimate

Logic
Test sends the selected activity ID and unsaved conditions object., The source counts distinct users in activity history matching the current activity and conditions., The source returns matching user count plus a sample of recent matching user IDs., Test does not create a rule and does not mutate tags., A successful estimate does not prove equivalent live webhook filtering.

Save payload split

Logic
If only Add Tag is enabled, the page submits one create payload with action `add`., If only Remove Tag is enabled, the page submits one create payload with action `remove`., If both are enabled, the page submits two create payloads., When both are enabled, the page appends `(Add)` and `(Remove)` to the generated rule names., The remove payload is submitted with priority one lower than the entered priority., Paired create requests are started concurrently.

Paired create caveat

Logic
Multiple create payloads are sent as separate concurrent create requests from the page wrapper., The verified page flow does not roll back an already-created first rule if another paired create fails., Operators should inspect the list before retrying after a paired-create failure.

Estimator and live condition divergence

Logic
The estimator query supports the transaction and user condition keys offered by the form., The live model evaluator supports `minCount`, `maxCount`, `minAmount`, `maxAmount`, and `timeFrame` only., None of those live-evaluator keys is offered by the current form., Operators must not treat Test Conditions as proof that live events enforce the saved form conditions.
Fields18 topicsOpen details

Clone From

Optional source rule ID from the page query. When present, the page loads that rule for a new copy.

Group
page-state
Data Type
integer
Caveats
The copied form name is suffixed with `(Copy)` and saved as a new rule, not an update to the source rule., Clone read has no dedicated loading, not-found, or error presentation; verify copied values before save., Scalar values can reinitialize after the source loads, but the local condition-row array is initialized earlier and is not reliably synchronized. Re-enter any missing conditions before save.

Rule Name

Human-readable rule name shown on the list and detail pages.

Group
rule-information
Data Type
string
Validation
Required: true

Activity

Activity event that triggers the rule.

Group
rule-information
Data Type
integer
Validation
Required: true

Description

Optional explanation for operators maintaining the rule.

Group
rule-information
Data Type
string

Enable Add Tag

Turns on the add-tag payload section.

Group
add-tag
Data Type
boolean

Tag Name to Add

Tag that will be added when the rule matches.

Group
add-tag
Data Type
string
Validation
Required When: add_tag_enabled

Enable Remove Tag

Turns on the remove-tag payload section.

Group
remove-tag
Data Type
boolean

Tag Name to Remove

Tag that will be removed when the rule matches.

Group
remove-tag
Data Type
string
Validation
Required When: remove_tag_enabled

Rule Priority

Execution order for the backend rule.

Group
priority
Data Type
integer
Validation
Required: true | Min: 0
Caveats
If both Add Tag and Remove Tag are enabled, the remove-tag rule is submitted with one less priority point.

Conditions

Optional matching criteria used only for supported transaction activities.

Group
conditions
Data Type
json-object
Caveats
Condition rows are visible only for the supported transaction activity codes., Estimator support does not prove equivalent live webhook evaluation.

Condition Type

Selects which property the condition evaluates.

Group
conditions
Data Type
enum
Values
status, sequence, amount, country, paymentMethod, paymentProvider, withdrawalWithoutDeposit, documentsSubmitted, kycStatus, idVerificationStatus
Caveats
This selects a key inside the stored JSON conditions object, not a separate database column., These keys are supported by the estimator; the live model evaluator currently supports a different key set., In the estimator, `idVerificationStatus=verified` means the user's document-label array is non-empty and `not_verified` means it is empty. This is the same predicate family as Documents Submitted, not a separate ID-verification status field.

Condition Value

Value used by the selected condition type.

Group
conditions
Data Type
mixed

Amount Operator

Controls how amount is compared when the condition type is Amount.

Group
conditions
Data Type
enum
Values
equals, greaterThan, lessThan
Caveats
Stored inside the amount condition JSON; it is not a separate database column., Despite the UI labels, `greaterThan` is inclusive (`amount >= value`) and `lessThan` is inclusive (`amount <= value`); `equals` uses exact numeric equality., Used by the estimator, not proven in the live event evaluator.

Active

Sets whether the new rule is active immediately after save.

Group
settings
Data Type
boolean

Test Results

Shows the count of users matching the current unsaved test payload and a short sample of user IDs.

Group
test-results
Data Type
summary
Caveats
A successful result proves estimator matching only, not live webhook enforcement.

Save Rule

Submits one or two rule create payloads based on enabled tag configurations.

Group
actions
Data Type
action

Test Conditions

Runs the unsaved activity/condition payload through the backend estimator.

Group
actions
Data Type
action

Back to List

Leaves the form and returns to the Activity Tag Rules list without saving.

Group
actions
Data Type
action
More help

Related pages

Activity Tag Rules

Operator documentation for activity-driven tag automation rules, including list, create, edit, detail inspection, and recent application history.

Activity Tag Rules / Detail

Rule inspection page with stored identity, conditions, timestamps, impact estimate, run action, delete action, and recent application history.

Activity Tag Rules / Edit

Edit flow for one stored rule or an existing grouped add/remove pair, including grouped form rebuild, condition testing, and update-only save behavior.

Activity Tag Rules / List

Main inventory for activity-driven tag rules, with search, activity and status filters, grouped rows, clone, edit, and run actions.

Activity Tag Rules / Applications

Read-only recent recorded application rows inside rule detail, including user ID, tag outcome, timestamp, and captured activity payload.

Auto Tags Manager

Operator documentation for automatic tag rules, including list monitoring, create or edit, queued job control, and manual rule ordering.