Create Mass Update Run
create_mass_update_runCreate a run that sets named fields to declared values across a scoped population, and/or applies Segments whose labels are written to a target field. Requires at least one of assignment_spec (which fields get which values) or segment_spec. Every record in scope gets the same change, which is what separates this from enrichment. TO SET AN OWNER, assign owner_id a literal user id from list_crm_users. That is a ONE-TIME correction and leaves no policy behind: records created later are unaffected, and nothing records why these records have that owner. Ongoing ownership by territory or any other rule is what an assignment run does instead, from configuration a person authors -- see get_assignment_config. TO DELETE RECORDS, set delete=true with a filter_spec and nothing else: contacts, leads or accounts on Salesforce; contacts or companies (object_type account) on HubSpot, which has no leads. A person always decides a delete. disposition 'propose' (the default for a delete) puts one proposal per record in the review queue, each approved by a person; 'queue' holds the run until a person approves it, which then deletes every record in scope; 'execute' is refused, and so is a delete with no filter_spec. ON SALESFORCE an account goes with its contacts, opportunities and cases, which each account's proposal counts, and every delete moves the record to the Recycle Bin and can be undone for 15 days. ON HUBSPOT a company's contacts and deals are not deleted, only unlinked; every delete moves the record to HubSpot's recycle bin, and undoing it recreates the record from LiveCRM's snapshot under a new id and links it back. Undo from the CRM write log or by reversing the run.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | A name for the run, shown in the Runs tab. Every record in scope gets the same change. | |
| delete | No | Delete the records in scope instead of changing their fields. On Salesforce: contacts, leads and accounts; an account goes with its contacts, opportunities and cases, which each account's proposal counts, and each delete moves the record to the Recycle Bin and can be undone for 15 days. On HubSpot: contacts and companies (account); a company's contacts and deals are NOT deleted, only unlinked, and each delete moves the record to HubSpot's recycle bin, where an undo recreates it from LiveCRM's snapshot under a new id. The run carries a scope (required) and nothing else. A person always decides: 'propose' (the default) puts one proposal per record in the review queue, approved one at a time; 'queue' waits for a person to approve the run, which then deletes every record in scope; 'execute' is refused. | |
| score_spec | No | Scores to publish to CRM fields. The value comes from an earlier score run; a record that run has not scored is skipped, not scored here. | |
| disposition | No | Who releases this run's writes. 'execute' dispatches the pass on request, which is the default and what every run has always done. 'queue' stamps the run awaiting_approval and launches nothing until a person approves it. 'propose' dispatches the pass, which computes everything and writes NOTHING to the CRM, putting one reviewable proposal in the queue per record it would have changed — so a person approves the changes one at a time instead of the run wholesale. A credential may ask for either form of review and may never release it. Note that 'propose' still SPENDS what computing spends: an enrichment set to propose buys the provider data and then queues the writes, because a value nobody fetched cannot be proposed. | execute |
| filter_spec | No | Which records this run covers, as a filter tree. Omit for the whole object. It DESCRIBES a population and is resolved when the run is DISPATCHED, so write what you mean -- the CRO at Skypoint is `account_name is Skypoint AND title contains CRO` -- and never look a record up to write one. You need no ids and no counts. Call list_filterable_fields first, for the field names and operators only. | |
| object_type | Yes | Which CRM object the run targets: contact, account or lead. | |
| segment_spec | No | Segments to apply, each with the CRM field its label is written to. The same shape as create_segmentation_run's segment_spec. | |
| connection_id | Yes | The CRM connection. Required. Call list_crm_connections to get one. | |
| assignment_spec | No | Field values to set: the object and a list of field assignments, all written in one pass. A run needs at least one of assignment_spec, segment_spec or score_spec, unless delete is true. |