MngUnlinkLeadsAffiliateByFilter

Unlinks every lead matching the supplied filter from its affiliate. Every record is processed on its own: a failure on one record does not stop the others. What exactly changes is described in Unlinking From an Affiliate.

The confirm flag decides whether anything is written. With confirm: false the command runs every check and returns the counters describing what would happen, without touching a record. With confirm: true the same run also persists the change. The response shape is identical in both modes.

The command is available through the manager command API only; there is no REST path for it. It is the bulk form of MngUnlinkLeadAffiliate. To unlink the rows selected in a table, pass their ids in whereIn: [["customer_id", [101, 102, 103]]].

Access Control

Allowed sessions:

• SESSION_MANAGER
• SESSION_ADMIN
• SESSION_DEALER
• SESSION_CRM_MANAGER
• SESSION_CRM_ADMIN

The caller must have CRM access, set_leads and set_marketing.

The requested deskFilter is first narrowed to the desks the caller may see, and then every selected record is checked individually against the caller's brand and desk scope.

Every call is written to the journal, successful ones included, together with a summary line of the counters. Each unlinked record is also logged with the manager, the customer_id and the previous affiliate id and code.

Request

Dry run for selected rows:

{
  "command": "MngUnlinkLeadsAffiliateByFilter",
  "extID": "1",
  "data": {
    "confirm": false,
    "filter": {
      "deskFilter": "*",
      "limit": 50000,
      "offset": 0,
      "whereIn": [["customer_id", [101, 102, 103]]]
    }
  }
}

Request Data

Top level:

Field	Type	Required	Description
confirm	bool	Yes	false reports what would change without writing. true applies the change
filter	object	Yes	Record selection

There is no fields object: the cleared fields are fixed by the operation.

filter object:

Field	Type	Required	Description
deskFilter	string	Yes	Desk wildcard mask, for example *, DESK_*, DESK_EU*,!DESK_EU_TEST. Must not be empty
limit	int	Yes	From 1 to 50000. Validated, but it does not limit how much is processed
offset	int	Yes	Minimum 0. Validated, but it does not limit how much is processed
where	array	No	[[field, operator, value], ...], all conditions must match
orWhere	array	No	OR comparison group; 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	Example: [["created_time", "desc"]]

Filter fields and operators are the same as for the customer table, including the lifecycle_flags operators has_all, has_any, and has_none. Common filter semantics are described in Table filter syntax; desk masks in Desks TCP API.

Response Data

{
  "confirm": true,
  "matched": 3,
  "updated": 1,
  "skipped": 1,
  "failed": 1,
  "failures": [
    {
      "customer_id": 103,
      "error": "PERMISSION_DENIED"
    }
  ]
}

Field	Type	Description
confirm	bool	Echo of the request flag
matched	int	Records selected by the filter, kind, brand scope, and desk mask
updated	int	Records actually unlinked. Always 0 when confirm is false
skipped	int	Records with no affiliate link, including records unlinked earlier
failed	int	Records that did not pass the per-record checks or could not be written
failures	array	One entry per failure with customer_id, error, and an optional message. Present only when non-empty

failures[].error values:

Error	Meaning
PERMISSION_DENIED	The record is outside the caller's brand or desk scope
RET_INVALID_DATA	The record's brand changed during the run
RET_NOT_FOUND	The record was deleted during the run
RET_ERROR	The marketing storage did not answer for this record

Reading the Counters

After an applied run the identity matched = updated + skipped + failed holds. On a dry run updated is 0 by definition, and the number of records that would be unlinked is matched - skipped - failed.

Repeating a Run

A record that is already unlinked is counted in skipped and not written again, so the same request can be repeated after a partial failure. A record whose customer write failed keeps its affiliate_id, is still linked, and is unlinked by the repeated run.

Response Statuses

Status	Condition
200	Dry run. Always, since nothing was meant to change
200	Applied, at least one record unlinked, no failures
207	Applied, at least one record unlinked, some failed
409	Applied, nothing was unlinked

Errors

HTTP	Error	Description
400	INVALID_DATA	Request validation failed
403	RET_NOT_ENOUGH_RIGHTS	Missing permission or missing scope

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