MngGetWorkflowTriggers

Returns workflow trigger definitions from the backend registry as a table: structure names the columns and every row is an array of values in that order. Without limit all matching triggers are returned.

Response format changed

Rows are positional arrays read against structure, not objects, and the response now carries count. Earlier versions returned rows as an array of trigger objects. Read every value by the index of its name in structure.

Access

Manager sessions: SESSION_MANAGER, SESSION_ADMIN, SESSION_DEALER, SESSION_CRM_MANAGER, SESSION_CRM_ADMIN.

Request Parameters

Name	Type	Required	Description
scope	int	No	0 CRM, 1 BO, 2 both/all
limit	int	No	From 1 to 1000. Omitted means all triggers
offset	int	No	Default 0
where	array	No	[[field, operator, value], ...]
orWhere	array	No	OR comparison group in [[field, operator, value], ...] format; at least one condition must match
whereNot	array	No	[[field, value], ...]
whereIn	array	No	[[field, [values...]], ...]
whereNotIn	array	No	[[field, [values...]], ...]
whereBetween	array	No	[[field, [from, to]], ...]
whereNotBetween	array	No	[[field, [from, to]], ...]
orderBy	array	No	One sort column, for example [["code", "asc"]]. Default: code ascending

Fields available in filters and orderBy:

Field	Type
code, entity_type	string
scope, payload_type	int

Operators: =, ==, !=, >, <, >=, <=, like. String comparison is case-insensitive, and string like matches a substring (% characters are ignored); strings support only =, ==, != and like. Conditions on other fields, or with a value of another type, do not match. allowed_actions and allowed_conditions are not filterable. Filters apply inside the session scope described below.

Scope filtering:

0 = CRM, returns CRM + BOTH triggers
1 = BO, returns BO + BOTH triggers
2 = BOTH, returns all triggers

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

For non-admin BO/CRM sessions backend always enforces session scope, even if client sends scope = 2.

Request

{
  "command": "MngGetWorkflowTriggers",
  "extID": "1",
  "data": {
    "scope": 0,
    "where": [
      ["code", "like", "deposit"]
    ]
  }
}

Response Data

Field	Type	Description
structure	string[]	Column names, in the order of values in every row
rows	array[]	Matching triggers for the requested page
count	int	Number of triggers matching all filters, before limit and offset

Columns:

Column	Type	Description
code	string	Trigger code
scope	int	0 CRM, 1 BO, 2 both
payload_type	int	Payload type of the trigger event
entity_type	string	Entity the trigger is raised for
allowed_actions	string[]	Action codes the trigger exposes
allowed_conditions	string[]	Condition fields the trigger exposes

{
  "structure": [
    "code",
    "scope",
    "payload_type",
    "entity_type",
    "allowed_actions",
    "allowed_conditions"
  ],
  "rows": [
    [
      "deposit.created",
      2,
      1,
      "trade",
      ["kyc.require_step", "notify.manager"],
      ["amount_usd", "trade.login"]
    ]
  ],
  "count": 1
}

Use this method first when building a workflow rule editor.

kyc.profile.submitted starts when a customer submits a KYC profile.

Cashier approval workflow triggers are:

• cashier.deposit.approved for a successfully credited manual deposit;
• cashier.withdrawal.approved for a successfully completed manual withdrawal.

Both have CRM scope, payload type 7, entity type cashier_transaction, and expose the cashier.publish_approved action. That action publishes the corresponding outbound Moleculer event. A rule is therefore required for external publication.

cashier.deposit.approved also exposes customer.email_template.request_delivery, which hands a mailer template chosen in the rule to the deposit's customer — see customer.email_template.delivery_requested. cashier.withdrawal.approved does not expose it.

The trigger account.margin_call.alert starts only when an account enters MARGINLEVEL_MARGINCALL; unchanged Margin Call recalculations, Stop Out and recovery do not start it. It has scope 2, so both BackOffice and CRM sessions receive it, payload type 8 and entity type account. It exposes the account.margin_call.publish action for conditional Moleculer publication and customer.email_template.request_delivery, which hands a mailer template chosen in the rule to the account's customer — see customer.email_template.delivery_requested. account.margin_call.publish itself keeps scope 1; actions are not filtered by scope, so CRM lists it for this trigger too.

deposit.created is the workflow trigger for an applied OP_BALANCE_IN finance record. In addition to notification, CRM and compliance actions, it exposes the restricted bonus.grant action. Conditions may use the balance-in amount, login, reason, comment, brand, account group and customer context.

credit.created is the workflow trigger for an applied OP_CREDIT_IN finance record: credit set by CreditIn, CreditInSync or a plugin. Credit has no approval step, and removing credit does not raise a trigger. The trigger has scope 2, payload type 1 and entity type trade, and its only action is customer.email_template.request_delivery — a generic template email without the credit amount, see customer.email_template.delivery_requested. Its conditions are those of withdrawal.created. Credit sources do not set reason, so a rule tells a manual credit from a plugin credit only by trade.comment.