Queue Proposed Change
queue_actionPropose ONE field change on ONE named record into the review queue, for a person to approve or reject. Nothing reaches the CRM: the row waits until somebody decides on it, and you cannot approve it yourself. This is the tool for a change you have worked out per record -- 'set this contact's status', 'put the churn context on this account' -- where a run over a filter would be the wrong shape because the records do not share one predicate. IT RUNS ONLY AS A STEP OF A PLAN: the plan a person confirmed is the explanation the reviewer reads beside the row, so a direct call is refused. Put it in a plan with create_plan. USE A RUN INSTEAD FOR A POPULATION: create_mass_update_run with disposition 'propose' queues the same kind of review row for every record matching a filter, in one step, and is cheaper and clearer than calling this once per record. FIELD NAMES ARE THE CANONICAL ONES list_filterable_fields returns, not the CRM's API names; they are translated here, and a field this connection cannot write is refused now rather than after somebody has approved it. UPDATES ONLY, on contacts, accounts and leads. It creates nothing and deletes nothing. THE REASONING IS NOT DECORATION: it is what the reviewer reads to decide, so say what changed and why rather than restating the field name.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| reasoning | Yes | Why this change, in the reviewer's terms. Shown on the queue row. | |
| record_id | Yes | The CRM's own id for the record. get_crm_record reads one by id. | |
| object_type | Yes | Which object the record is. | |
| connection_id | Yes | The CRM connection. Call list_crm_connections first. | |
| field_changes | Yes | Canonical field name to the value to write, as list_filterable_fields names them. At least one. |