Page body
What this module is for
Use Activity Tag Rules to automate player tag changes after a tracked activity happens in CRM. Operators come here to define what activity should trigger the rule, which tag should be added or removed, and which conditions should narrow the affected users.
Main surfaces
Activity Tag Rules / Listis the operational inventory for all saved rules.Activity Tag Rules / Createis the create flow, including clone-from-existing behavior.Activity Tag Rules / Editis the grouped editor that can update one or two backend rules from one screen.Activity Tag Rules / Detailis the inspection surface with estimate, run, and delete actions.Activity Tag Rules / Applicationsis the recent audit trail shown inside the detail page.
What operators need to know first
- The list groups paired backend rules into one visible row when the FE decides they belong together. One visible row can represent both an
Addrule and aRemoverule. - The create and edit screens can save either one backend rule or two backend rules depending on whether
Add Tag,Remove Tag, or both sections are enabled. - Conditions are available only for the transaction activity codes currently hard-coded in FE:
FAILED_WITHDRAWAL,SUCCESS_WITHDRAWAL,SUCCESS_DEPOSIT, andFAILED_DEPOSIT. Estimate Impactis backed by SQL overuser_activitiesandusers.Run Ruleis routed through a backend execution endpoint, but the current verified service does not prove a full batch mutation loop for all matched users.
Backend verification summary
The verified ownership for this module is in gs-admin-backend:
GET /api/admin/activity-tag-rulesPOST /api/admin/activity-tag-rulesGET /api/admin/activity-tag-rules/:ruleIdPUT /api/admin/activity-tag-rules/:ruleIdDELETE /api/admin/activity-tag-rules/:ruleIdPOST /api/admin/activity-tag-rules/testPOST /api/admin/activity-tag-rules/:ruleId/estimatePOST /api/admin/activity-tag-rules/:ruleId/runGET /api/admin/activity-tag-rules/:ruleId/applicationsGET /api/admin/activities
Supporting condition-option data also uses GET|POST /api/admin/payment-methods/crud through the shared payment-method hook.
No gs-casino-backend ownership was required for the currently verified operator surfaces.
Important caveats
- The backend stores these rules in
auto_tag_rules, even though the FE and operator-facing UI use the wordingActivity Tag Rules. - The verified estimate query supports only the condition set implemented in
buildActivityEstimateQuery. If an FE field exists but is not in that query, operators should not assume estimate coverage. - The detail page shows only the latest applications requested by FE, not an unlimited full-history screen.