Skip to content

MngGetWorkflowTriggers

Returns all workflow trigger definitions from the backend registry.

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

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
  }
}

Response Data

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

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.