Create Scoring Run
create_score_runCreate a run that scores a population against a scoring model: a weighted composite over banded inputs, with thresholds naming the result. WRITES NOTHING TO THE CRM. The score lands in LiveCRM, where it immediately becomes filterable -- after this run, <slug>_score and <slug>_band are fields any filter may name, so 'the top band' is a scope rather than a second export.
WHICH MODEL: the template_id you name, or the connection's model for that object when you name none. Call list_rule_templates with tool_type=scoring to see them; a run finding no model declines rather than failing.
TO PUT A SCORE IN A CRM FIELD, that is a separate create_mass_update_run carrying a score_spec. Publishing is optional and is its own decision, because it writes to the customer's org and this does not.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | A name for the run, shown in the Runs tab. It computes and stores a score; it writes nothing to the CRM. | |
| publish | No | Where the score is also written in the CRM: each entry publishes the 'band' (the label) or the 'score' (the number) to a field, by default the model's own target field. Omit or leave empty to compute only: the score is kept in LiveCRM, where filters can use it, and nothing is written to the CRM. | |
| 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. | |
| template_id | No | The scoring model this run applies, by id (list_rule_templates). Omit to use the connection's model for this object; the run declines by name when there is none. | |
| connection_id | Yes | The CRM connection. Required. Call list_crm_connections to get one. |