Create Enrichment Run
create_enrichment_runCreate a run that fetches missing field values from a data provider and writes them to the CRM. THIS ONE SPENDS MONEY when dispatched: up to one credit per record sent, and nothing for a record the provider already licensed. credit_cap is required and has no default -- it is the ceiling on the credits the provider charges, and the run stops before a call that could pass it. template_id names the configuration -- which provider fields map to which CRM fields, and when a value may replace an existing one -- which a person authors; list them with list_rule_templates and read one with get_rule_template. Preview before dispatching.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | A name for the run, shown in the Runs tab. Dispatching this spends up to one provider credit per record sent. | |
| credit_cap | Yes | Required: the most provider credits this run may spend. There is no default, so the number is always stated before anything is spent. | |
| firing_cap | No | Only in a staged plan: the most records one firing asks the provider about through this run, at most 10,000, which is also the default. A run outside a staged plan ignores it; its credit cap is its only bound. | |
| 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 | Yes | Required: the enrichment configuration to use, by id (list_rule_templates): which fields to request and how each value is written. It must target this run's object. | |
| connection_id | Yes | The CRM connection. Required. Call list_crm_connections to get one. | |
| segments_when | No | Only 'overwrite', or omit. With 'overwrite', the fields this run writes through a value map (Industry, the band fields, Persona) replace values the CRM already holds with standardized ones, whatever each configuration row says; the rows keep their setting for every other run. A run in a staged plan ignores it. | |
| ask_again_after_days | No | Skip records this provider was already asked about within this many days. Omit to ask about every record in the scope, which is the default and what a one-off run normally wants. Set it on a run that REPEATS over a standing scope: without it, every firing asks the provider about the whole book again to find the few records that changed. The ledger it reads is shared across runs, so another run's ask suppresses this one's. |