MngGetWorkflowRulesByFilter¶
Returns workflow rules with filters and pagination.
Access¶
Manager sessions: SESSION_MANAGER, SESSION_ADMIN, SESSION_DEALER, SESSION_CRM_MANAGER, SESSION_CRM_ADMIN.
Request Parameters¶
| Name | Type | Required | Description |
|---|---|---|---|
brand |
string | No | Brand namespace |
trigger |
string | No | Trigger code |
status |
int | No | -1 or omitted means all statuses |
scope |
int | No | 0 CRM, 1 BO, 2 both/all |
limit |
int | No | Default 100, max 1000 |
offset |
int | No | Default 0 |
Scope filtering:
0 = CRM, returns CRM + BOTH rules
1 = BO, returns BO + BOTH rules
2 = BOTH, returns all rules
If scope is omitted, backend infers it from __access.type:
SESSION_CRM_MANAGER / SESSION_CRM_ADMIN -> CRM
SESSION_MANAGER / SESSION_DEALER -> BO
SESSION_ADMIN -> BOTH
This prevents CRM-only workflow chains from appearing in BackOffice UI and BO-only workflow chains from appearing in CRM UI.
For non-admin BO/CRM sessions backend always enforces session scope, even if client sends scope = 2.
Request¶
{
"command": "MngGetWorkflowRulesByFilter",
"extID": "1",
"data": {
"brand": "brand-a",
"trigger": "deposit.created",
"status": 0,
"scope": 0,
"limit": 100,
"offset": 0
}
}
Response Data¶
{
"rows": [
{
"id": 1,
"brand": "brand-a",
"code": "large_deposit_sof",
"name": "Large Deposit Source Of Funds",
"trigger": "deposit.created",
"conditions": [],
"actions": [],
"status": 0
}
],
"count": 1
}