MngSetCustomerLifecycleFlags

Sets the lifecycle milestones of one customer by writing the whole lifecycle_flags mask.

The command is available through the manager command API only; there is no REST path for it. The request carries the target mask rather than an increment: the server compares it with the current value and works out which bits to raise and which to clear.

Flag values are listed in Lifecycle Flags.

Access Control

Allowed sessions:

• SESSION_MANAGER
• SESSION_ADMIN
• SESSION_DEALER
• SESSION_CRM_MANAGER
• SESSION_CRM_ADMIN

The caller must have CRM access and set_customers. Beyond the permission, the target customer is checked against the caller's brand and desk scope.

Every call is written to the journal, successful ones included.

Request

Raise Registered, KYC approved, and First deposit, which is 1 + 4 + 8:

{
  "command": "MngSetCustomerLifecycleFlags",
  "extID": "1",
  "data": {
    "customer_id": 500,
    "lifecycle_flags": 13
  }
}

Clear every flag:

{
  "command": "MngSetCustomerLifecycleFlags",
  "extID": "2",
  "data": {
    "customer_id": 500,
    "lifecycle_flags": 0
  }
}

An empty mask is a valid state, not an error: the customer has reached no milestone yet. That is exactly how a fresh lead looks.

Request Data

Field	Type	Required	Description
customer_id	int	Yes	Target customer id, 1 or greater
lifecycle_flags	int64	Yes	Whole target mask, 0..63

The upper bound 63 is the sum of all six known bits. A higher value is rejected.

Response Data

{
  "customer_id": 500,
  "lifecycle_flags": 13
}

Field	Type	Description
customer_id	int	The identifier passed in the request
lifecycle_flags	int64	The resulting mask

Behavior

When the mask actually changes, updated_time is refreshed and two events are published: the internal customer.push record with code EV_RECORD_UPDATE, and the internal customer.updated record carrying the previous status, mask, and kind. Modules receive the latter as customer.update.

The conversion fields conversion_flags and conversion_time are never touched here. They change only when customer_kind changes; see Lead and Client Kind.

Sending the Mask a Customer Already Has

When the supplied mask equals the current one, the command answers 200 with that value and writes nothing: no update, no events, no journal entry for a change.

The call is therefore safe to repeat. This differs from MngConvertLeadToClient and MngConvertClientToLead, where repeating a completed conversion is refused.

No State-Based Refusal

Unlike the conversion commands, this one never answers RET_INVALID_DATA because of the customer's current state. Any valid mask applies to any customer: the flags are independent and no combination is forbidden. KYC pending and KYC approved may stand together, and the server does not object.

Errors

HTTP	Error	Description
400	INVALID_DATA	Validation failed: customer_id or lifecycle_flags is missing, has the wrong type, or the mask is outside 0..63
403	RET_NOT_ENOUGH_RIGHTS	Missing permission, missing scope, or the customer is outside the caller's visibility
404	RET_NOT_FOUND	No customer with that identifier exists

Every error carries a message field with free-form text. Its contents are not part of the contract; branch on error.

Other Ways to Change the Mask

Method	Form
MngSetCustomerLifecycleFlags	Whole mask, bounded to 0..63
MngAddCustomer, MngUpdateCustomer	Whole mask in the lifecycle_flags field, upper bound not checked
MngUpdateCustomersByFilter	Increments lifecycle_flags_add and lifecycle_flags_remove
Workflow action customer.set_lifecycle_flags	Increments add and remove, at least one required

This command is the only one that bounds the value from above. Bits outside the dictionary written through MngAddCustomer or MngUpdateCustomer are stored as supplied and are displayed nowhere.

Increments rather than a whole mask are used by the bulk command and the workflow action deliberately: a filtered selection is heterogeneous, so there is no single correct mask for all of it. Here the manager is looking at one customer card and sets the complete set knowingly.

The engine never raises or clears a flag by itself: not KYC, not Cashier, not the trading loop. A deposit alone does not mark First deposit; without an active workflow rule the flag does not appear.

The canonical source of the labels is the enum_values list of the customer.lifecycle_flags condition returned by MngGetWorkflowConditionsByTrigger. CRM responses carry the number alone.