Create Segmentation Run
create_segmentation_runCreate a run that classifies a population into a Segment's named groups and writes each record's winning label to a CRM field. A Segment is authored on the Rules page and holds named entries with predicates; this applies one to a scope. IT ALWAYS WRITES, unlike a scoring run, and the difference is worth knowing before composing one: a score has somewhere else to live -- LiveCRM's own store, where it is immediately filterable -- and a segment label does not. Nothing stores it, so a segmentation run that wrote nothing would compute a label and discard it. There is no compute-only form and no write_back to set. A SEGMENT NAMES ABSTRACT LABELS, not fields, which is what lets ONE Segment serve contacts, leads and accounts. Each application must therefore bind every label the Segment references to a real field on THIS object, and name the target field its winning label is written to. Call list_rule_templates with tool_type=segment to see the Segments and the labels each one uses. FIRST MATCH WINS per record, in the order the Segment's entries are authored. A record matching no entry is left ALONE rather than cleared, unless the Segment carries a default -- absent and unclassified are different facts, and clearing a field a rep may be reading is a destructive answer to the second.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | A name for the run, shown in the Runs tab. It writes each record's segment label to the field the application names. | |
| 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 | Required: the Segments to apply, at least one, each with the CRM field its winning label is written to and the binding from its labels to this object's fields. A segmentation run always writes the label; it is not stored anywhere else. | |
| connection_id | Yes | The CRM connection. Required. Call list_crm_connections to get one. |