feat(servicenow): semantic incident, change, catalog, approval, CMDB, and knowledge tools (#6747)

* feat(servicenow): add semantic incident, change, catalog, approval, CMDB, knowledge, and directory tools

The ServiceNow block only exposed generic Table API CRUD, so every real task
started with "which table is that on?". This adds 27 semantic tools that wrap
the same Table API plumbing under the names customers actually use.

- Incidents: create, get by number or sys_id, search, update, resolve, close,
  and append a work note or customer-visible comment.
- Change: create, get, list, update, move state, and list change tasks through
  the documented Change Management API.
- Service catalog: browse items, order one via the Service Catalog API
  order_now endpoint, and list or get requested items.
- Approvals: list pending approvals for an approver, approve, and reject.
- CMDB: search CIs on any class, read a CI with its inbound and outbound
  relations through the CMDB Instance API, and list cmdb_rel_ci rows.
- Knowledge: search and read articles through the Knowledge Management API.
- Directory: find a user by email or user name and list group members, which
  is what fills assigned_to and assignment_group.

Reference fields are the usual source of confusion, so every semantic read
defaults to sysparm_display_value=all — a reference comes back as both its
sys_id and its label — and every semantic write exposes
sysparm_input_display_value so a display name can be written instead of a
sys_id. Coded state values are exposed as labelled dropdowns built from one
constants module rather than raw integers.

The shared instance-URL, Basic Auth, sysparm, envelope, and error handling now
live in tools/servicenow/utils.ts, and the existing eight generic tools were
moved onto it rather than keeping their own copies.

* fix(servicenow): stop per-operation subblock defaults colliding on a shared id

Subblock initial values are seeded into block state keyed by subblock id, so
two subblocks sharing an id leave one stored value and the last definition
wins. Three ids were duplicated with differing defaults:

- `displayValue` was defined twice, unset for the generic Table API tools and
  `all` for the semantic ones. The semantic definition won, so a new block set
  to Read Records or Aggregate Records sent `sysparm_display_value=all` — a
  wire change to two already-shipped tools.
- `state` was defined four times. The Approval State definition won, so every
  new block carried `state=requested`, which Create Incident wrote to the
  incident and Move Change State used instead of its own `-5` default.

Give the colliding controls their own ids and map them back to the tool params
per operation, so the generic tools keep their original request shape and each
semantic operation keeps its own default.

Also correct descriptions that overstated what the API does: the LIKE operator
is not documented as case-sensitive, List Requested Items has no requester
filter, and the Change Management API task shape differs from the Table API.

Adds tool tests covering the refactor invariants for the eight pre-existing
Table API tools and the display-value separation.

* feat(servicenow): read a change request's real next states from the instance

The change tools describe state transitions using the base-system codes, which
only hold on an instance that has not customized its change model. ServiceNow
publishes an endpoint that answers the question directly for the record in
hand, so use it rather than keep assuming.

GET /api/sn_chg_rest/change/{sys_id}/nextstates returns the states reachable
from the change request, the instance's own state-value-to-label map, and, for
model-driven changes, each transition with the conditions it has and has not
met. The tool flattens the per-target-state grouping ServiceNow returns (each
transition already carries from_state and to_state, so nothing is lost) and
derives the states whose conditions currently pass.

Also record the sourcing for the coded values in constants.ts: the change
states and close codes are published as a table, but the incident state codes
are not — only 6 (Resolved) appears in the docs — so mark the rest as defaults
rather than guarantees. Note that sysparm_input_display_value also reinterprets
date and time values in the caller's timezone instead of GMT, which matters for
the change start and end dates.

* docs(servicenow): stop asserting undocumented coded values in placeholders

The additional-fields examples used hold_reason with a coded value of "1".
ServiceNow documents the On hold reason choices by label only — Awaiting
Caller, Awaiting Change, Awaiting Problem, Awaiting Vendor — and publishes
neither the column name nor the codes, so the example was asserting something
unsourced. Use a field whose value is caller-supplied instead, and record the
On Hold requirement on the incident state control using the labels the docs
actually give, including that Awaiting Caller makes Additional Comments
mandatory.

* fix(servicenow): drop phantom parent fields from the catalog order output

order_catalog_item read parent_id and parent_table off the order_now response.
Those fields belong to submit_producer, a different Service Catalog endpoint;
the documented order_now result is sys_id, number, request_number, request_id,
and table. Both outputs were therefore always null.

* fix(servicenow): correct what knowledge search returns as an article id

Search results carry a table-prefixed identifier — "kb_knowledge:9e528db1..."
— not a bare sys_id, while GET /knowledge/articles/{id} accepts only a bare
sys_id or a KB number. The output described it as a sys_id and the tool
description told callers it was what they needed to fetch the article, so
chaining the two tools on that field would fail. Point callers at the KB
number instead. Relevancy score is documented as a number, not a string.

* docs(servicenow): cite the page that actually documents approval statuses

The approval state constants pointed at the classic-approvals landing page,
which does not list the statuses. Approval status is documented separately and
names four — Requested, Approved, Rejected, and Not Requested.

* fix(servicenow): stop constant interpolation leaking into tool descriptions

The docs generator and the client-facing integration catalog read tool
descriptions from source rather than from the evaluated module, so a
template literal like `state ${INCIDENT_STATE.RESOLVED}` shipped to users
verbatim: `apps/sim/lib/integrations/integrations.json` and the published
ServiceNow integration page both rendered `${INCIDENT_STATE.RESOLVED}`
instead of `6`. Inline the base-system coded values in the description
text; the constants stay in use everywhere behavior depends on them.

Also drops an escaped `\'` in the `inputDisplayValue` description for the
same reason, and adds a standing guard test asserting no subBlock id
carries two different seeded defaults — the invariant behind the
per-operation defaulting bug, now checked structurally rather than only
through the four per-operation cases.

* refactor(servicenow): type the shared response boundary instead of any

`parseServiceNowResponse` returned `any`, so every tool reading `data.result`
did unchecked property access — a shape change on the instance side would have
produced a wrong-typed output silently rather than a type error.

Introduces `ServiceNowEnvelope` (`result?: unknown`) as the parser's return
type and narrows the record index signatures from `any` to `unknown`. Adds
`toRecordObject`, `readString`, and `readNestedNumber` so the tools that read
individual fields narrow deliberately at the point of use.

This surfaced five genuinely unchecked reads: Order Catalog Item, Get Knowledge
Article, and Search Knowledge were declaring `string | null` / `number | null`
outputs while emitting whatever the instance sent, and Get Change Next States
assigned an unvalidated object to `Record<string, string>`. Each now coerces or
drops a non-matching value rather than passing it through.

* fix(servicenow): publish the shared tool params and stop offering inert controls

The docs generator reads tool source rather than importing it, so the shared
`params.ts` consts the semantic tools spread were dropped from every published
Input table — 27 of 35 ServiceNow tools listed no instance URL, username, or
password at all. Follow a spread into the module it is imported from so those
rows are published; ten other integrations gain the rows they were missing for
the same reason.

Two controls were dead on arrival: Additional Fields was offered on Move Change
State and Add Incident Comment, and neither tool read it. Wire it through the
change transition, which needs it, and drop it from the comment tool, whose body
is exactly one journal field.

Every coded-value control was a select-only dropdown, so a customized instance's
state or close code was unreachable — sharpest on Move Change State, whose
target state is required and whose real codes come from Get Change Next States.
Make them comboboxes.

Also correct two doc claims ServiceNow does not publish (the incident state
citation pointed at a page that does not exist and compares the legacy
incident_state field; closing an incident is not documented as requiring
itil_admin), replace Record<string, any> with checked narrowing that surfaced
two unsound widenings, and document that List Change Tasks returns a fixed
{value, display_value} shape under `tasks` rather than `records`.

* fix(servicenow): stop one subblock id from carrying two value spaces

Subblock values are stored per block keyed by id, so an id reused across
operations keeps its value when the operation changes. Incident and change
shared `state`, and `closeCode`, `closeNotes`, `comments`, and the knowledge
search phrase were each reused for a different value space — so an incident
state could be written onto a change request, an incident close code sent as a
change close code, or an encoded query searched as knowledge text.

Give each value space its own subblock and republish it to the tool param from
the operation that owns it, the way targetState and approvalState already work.
The generic Table API ids stay exactly as they are, since renaming one would
orphan the stored value of every workflow already using those shipped tools.

The previous guard only compared seeded defaults, which is why this class stayed
hidden; the new one asserts against the merged params a tool actually receives.

* fix(servicenow): point the canvas sentences at the renamed subblocks

The split of the colliding subblock ids left the operation sentences anchored on
ids that no longer exist, so those clauses would silently drop from the card.

* fix(servicenow): validate collection members and split the fields projection

toRecordArray cast every member of a successful response, so a null or scalar in
a collection was handed to the next block as a record while the tool reported
success and its declared output said that could not happen. Members that are not
plain objects are now dropped, and knowledge articles and change transitions get
the same narrowing. The two response types that described an unverified inner
shape now say what is actually checked.

The 'fields' subblock also carried two value spaces: a JSON body on Create and
Update Record, a comma-separated projection everywhere else. Operations added
since read a separate returnFields control, so a body can no longer arrive as a
projection or the reverse. The shipped ids are untouched, since renaming one
orphans the stored value of every workflow already using those tools.

Author: waleedlatif1

apps/docs/content/docs/en/integrations/emailbison.mdx

@@ -40,6 +40,8 @@ Retrieves leads from Email Bison with optional search and tag filters.
 
 | Parameter | Type | Required | Description |
 | --------- | ---- | -------- | ----------- |
+| `apiKey` | string | Yes | Email Bison API token |
+| `apiBaseUrl` | string | Yes | Email Bison instance URL that issued the token |
 | `search` | string | No | Search term for filtering leads |
 | `campaignStatus` | string | No | Lead campaign status filter: in_sequence, sequence_finished, sequence_stopped, never_contacted, or replied |
 | `tagIds` | array | No | Tag IDs to include |
@@ -73,6 +75,8 @@ Retrieves a lead by Email Bison lead ID or email address.
 
 | Parameter | Type | Required | Description |
 | --------- | ---- | -------- | ----------- |
+| `apiKey` | string | Yes | Email Bison API token |
+| `apiBaseUrl` | string | Yes | Email Bison instance URL that issued the token |
 | `leadId` | string | Yes | Lead ID or email address |
 
 #### Output
@@ -102,6 +106,8 @@ Creates a single lead in Email Bison.
 
 | Parameter | Type | Required | Description |
 | --------- | ---- | -------- | ----------- |
+| `apiKey` | string | Yes | Email Bison API token |
+| `apiBaseUrl` | string | Yes | Email Bison instance URL that issued the token |
 | `firstName` | string | Yes | Lead first name |
 | `lastName` | string | Yes | Lead last name |
 | `email` | string | Yes | Lead email address |
@@ -137,6 +143,8 @@ Updates an existing Email Bison lead. Fields omitted from a PUT update may be cl
 
 | Parameter | Type | Required | Description |
 | --------- | ---- | -------- | ----------- |
+| `apiKey` | string | Yes | Email Bison API token |
+| `apiBaseUrl` | string | Yes | Email Bison instance URL that issued the token |
 | `leadId` | string | Yes | Lead ID or email address |
 | `firstName` | string | Yes | Lead first name |
 | `lastName` | string | Yes | Lead last name |
@@ -173,6 +181,8 @@ Retrieves Email Bison campaigns.
 
 | Parameter | Type | Required | Description |
 | --------- | ---- | -------- | ----------- |
+| `apiKey` | string | Yes | Email Bison API token |
+| `apiBaseUrl` | string | Yes | Email Bison instance URL that issued the token |
 
 #### Output
 
@@ -201,6 +211,8 @@ Creates a new Email Bison campaign.
 
 | Parameter | Type | Required | Description |
 | --------- | ---- | -------- | ----------- |
+| `apiKey` | string | Yes | Email Bison API token |
+| `apiBaseUrl` | string | Yes | Email Bison instance URL that issued the token |
 | `name` | string | Yes | Campaign name |
 | `campaignType` | string | No | Campaign type: outbound or reply_followup |
 
@@ -231,6 +243,8 @@ Updates Email Bison campaign settings.
 
 | Parameter | Type | Required | Description |
 | --------- | ---- | -------- | ----------- |
+| `apiKey` | string | Yes | Email Bison API token |
+| `apiBaseUrl` | string | Yes | Email Bison instance URL that issued the token |
 | `campaignId` | number | Yes | Campaign ID |
 | `name` | string | No | Campaign name |
 | `maxEmailsPerDay` | number | No | Maximum emails per day |
@@ -269,6 +283,8 @@ Pauses, resumes, or archives an Email Bison campaign.
 
 | Parameter | Type | Required | Description |
 | --------- | ---- | -------- | ----------- |
+| `apiKey` | string | Yes | Email Bison API token |
+| `apiBaseUrl` | string | Yes | Email Bison instance URL that issued the token |
 | `campaignId` | number | Yes | Campaign ID |
 | `action` | string | Yes | Status action: pause, resume, or archive |
 
@@ -299,6 +315,8 @@ Adds existing Email Bison leads to a campaign.
 
 | Parameter | Type | Required | Description |
 | --------- | ---- | -------- | ----------- |
+| `apiKey` | string | Yes | Email Bison API token |
+| `apiBaseUrl` | string | Yes | Email Bison instance URL that issued the token |
 | `campaignId` | number | Yes | Campaign ID |
 | `leadIds` | array | Yes | Lead IDs to add to the campaign |
 | `allowParallelSending` | boolean | No | Force add leads already in sequence in other campaigns |
@@ -330,6 +348,8 @@ Retrieves Email Bison replies with optional status, folder, campaign, sender, le
 
 | Parameter | Type | Required | Description |
 | --------- | ---- | -------- | ----------- |
+| `apiKey` | string | Yes | Email Bison API token |
+| `apiBaseUrl` | string | Yes | Email Bison instance URL that issued the token |
 | `search` | string | No | Search term for replies |
 | `status` | string | No | Reply status: interested, automated_reply, or not_automated_reply |
 | `folder` | string | No | Reply folder: inbox, sent, spam, bounced, or all |
@@ -366,6 +386,8 @@ Retrieves all Email Bison tags for the authenticated workspace.
 
 | Parameter | Type | Required | Description |
 | --------- | ---- | -------- | ----------- |
+| `apiKey` | string | Yes | Email Bison API token |
+| `apiBaseUrl` | string | Yes | Email Bison instance URL that issued the token |
 
 #### Output
 
@@ -394,6 +416,8 @@ Creates a new Email Bison tag.
 
 | Parameter | Type | Required | Description |
 | --------- | ---- | -------- | ----------- |
+| `apiKey` | string | Yes | Email Bison API token |
+| `apiBaseUrl` | string | Yes | Email Bison instance URL that issued the token |
 | `name` | string | Yes | Tag name |
 
 #### Output
@@ -423,6 +447,8 @@ Attaches Email Bison tags to one or more leads.
 
 | Parameter | Type | Required | Description |
 | --------- | ---- | -------- | ----------- |
+| `apiKey` | string | Yes | Email Bison API token |
+| `apiBaseUrl` | string | Yes | Email Bison instance URL that issued the token |
 | `tagIds` | array | Yes | Tag IDs to attach |
 | `leadIds` | array | Yes | Lead IDs to tag |
 | `skipWebhooks` | boolean | No | Skip Email Bison webhooks for this action |

apps/docs/content/docs/en/integrations/file.mdx

@@ -73,6 +73,8 @@ Fetch and parse a file from a URL with optional custom headers.
 
 | Parameter | Type | Required | Description |
 | --------- | ---- | -------- | ----------- |
+| `request` | string | No | No description |
+| `outputs` | array | No | Array of parsed files with content and metadata |
 | `headers` | object | No | HTTP headers to include when fetching URL-based files. |
 
 #### Output

apps/docs/content/docs/en/integrations/flint.mdx

@@ -49,6 +49,7 @@ Start a background Flint agent task that modifies a site from a natural-language
 
 | Parameter | Type | Required | Description |
 | --------- | ---- | -------- | ----------- |
+| `apiKey` | string | Yes | Flint API key \(found in Flint team settings, starts with ak_\) |
 | `siteId` | string | Yes | ID of the Flint site the agent should modify |
 | `prompt` | string | Yes | Natural-language instructions for the agent \(e.g., "Add a new About page with a team section"\) |
 | `callbackUrl` | string | No | HTTPS webhook URL that Flint will POST to when the task completes or fails |
@@ -70,6 +71,7 @@ Start a background Flint agent task that generates up to 10 pages from a templat
 
 | Parameter | Type | Required | Description |
 | --------- | ---- | -------- | ----------- |
+| `apiKey` | string | Yes | Flint API key \(found in Flint team settings, starts with ak_\) |
 | `siteId` | string | Yes | ID of the Flint site the agent should modify |
 | `templatePageSlug` | string | Yes | Slug of the existing template page to generate from \(e.g., /case-studies/template\) |
 | `items` | json | Yes | JSON array of 1-10 pages to generate. Each item requires targetPageSlug \(slug for the new page\) and context \(content details the agent should use\). |
@@ -92,6 +94,7 @@ Get the status and results of a background Flint agent task.
 
 | Parameter | Type | Required | Description |
 | --------- | ---- | -------- | ----------- |
+| `apiKey` | string | Yes | Flint API key \(found in Flint team settings, starts with ak_\) |
 | `taskId` | string | Yes | Identifier of the task returned when it was created \(e.g., bg-...\) |
 
 #### Output

apps/docs/content/docs/en/integrations/github.mdx

@@ -43,6 +43,10 @@ Fetch PR details including diff and files changed
 
 | Parameter | Type | Required | Description |
 | --------- | ---- | -------- | ----------- |
+| `owner` | string | Yes | Repository owner |
+| `repo` | string | Yes | Repository name |
+| `pullNumber` | number | Yes | Pull request number |
+| `apiKey` | string | Yes | GitHub API token |
 | `includeFiles` | boolean | No | Whether to fetch changed-file details from the separate files endpoint |
 
 #### Output

apps/docs/content/docs/en/integrations/instantly.mdx

@@ -40,6 +40,7 @@ Retrieves Instantly V2 leads with search, campaign, list, and pagination filters
 
 | Parameter | Type | Required | Description |
 | --------- | ---- | -------- | ----------- |
+| `apiKey` | string | Yes | Instantly API key with the required V2 scopes |
 | `search` | string | No | Search by first name, last name, or email |
 | `filter` | string | No | Instantly lead filter value, such as FILTER_VAL_CONTACTED or FILTER_VAL_ACTIVE |
 | `campaign` | string | No | Campaign ID to filter leads |
@@ -90,6 +91,7 @@ Retrieves an Instantly V2 lead by ID.
 
 | Parameter | Type | Required | Description |
 | --------- | ---- | -------- | ----------- |
+| `apiKey` | string | Yes | Instantly API key with the required V2 scopes |
 | `leadId` | string | Yes | Lead ID |
 
 #### Output
@@ -124,6 +126,7 @@ Creates an Instantly V2 lead in a campaign or lead list.
 
 | Parameter | Type | Required | Description |
 | --------- | ---- | -------- | ----------- |
+| `apiKey` | string | Yes | Instantly API key with the required V2 scopes |
 | `campaign` | string | No | Campaign ID associated with the lead |
 | `list_id` | string | No | Lead list ID associated with the lead |
 | `email` | string | No | Lead email address. Required when adding to a campaign. |
@@ -177,6 +180,7 @@ Updates fields on an existing Instantly V2 lead.
 
 | Parameter | Type | Required | Description |
 | --------- | ---- | -------- | ----------- |
+| `apiKey` | string | Yes | Instantly API key with the required V2 scopes |
 | `leadId` | string | Yes | Lead ID |
 | `first_name` | string | No | Lead first name |
 | `last_name` | string | No | Lead last name |
@@ -222,6 +226,7 @@ Deletes Instantly V2 leads in bulk from a campaign or lead list.
 
 | Parameter | Type | Required | Description |
 | --------- | ---- | -------- | ----------- |
+| `apiKey` | string | Yes | Instantly API key with the required V2 scopes |
 | `campaign_id` | string | No | Campaign ID to delete leads from. Required if list_id is not provided. |
 | `list_id` | string | No | Lead list ID to delete leads from. Required if campaign_id is not provided. |
 | `status` | number | No | Optional lead status filter |
@@ -242,6 +247,7 @@ Submits an Instantly V2 background job to update a lead interest status.
 
 | Parameter | Type | Required | Description |
 | --------- | ---- | -------- | ----------- |
+| `apiKey` | string | Yes | Instantly API key with the required V2 scopes |
 | `lead_email` | string | Yes | Lead email address |
 | `interest_value` | number | No | Interest status value. Leave empty in the block or pass null to reset to Lead. |
 | `campaign_id` | string | No | Campaign ID for the lead |
@@ -263,6 +269,7 @@ Retrieves Instantly V2 campaigns with search, status, tag, and pagination filter
 
 | Parameter | Type | Required | Description |
 | --------- | ---- | -------- | ----------- |
+| `apiKey` | string | Yes | Instantly API key with the required V2 scopes |
 | `limit` | number | No | Number of campaigns to return, from 1 to 100 |
 | `starting_after` | string | No | Pagination cursor from next_starting_after |
 | `search` | string | No | Search by campaign name |
@@ -302,6 +309,7 @@ Creates an Instantly V2 campaign using the documented campaign schedule schema.
 
 | Parameter | Type | Required | Description |
 | --------- | ---- | -------- | ----------- |
+| `apiKey` | string | Yes | Instantly API key with the required V2 scopes |
 | `name` | string | Yes | Campaign name |
 | `campaign_schedule` | json | Yes | Campaign schedule object with schedules array |
 | `sequences` | array | No | Campaign sequence definitions |
@@ -347,6 +355,7 @@ Updates documented Instantly V2 campaign fields.
 
 | Parameter | Type | Required | Description |
 | --------- | ---- | -------- | ----------- |
+| `apiKey` | string | Yes | Instantly API key with the required V2 scopes |
 | `campaignId` | string | Yes | Campaign ID |
 | `name` | string | No | Campaign name |
 | `campaign_schedule` | json | No | Campaign schedule object with schedules array |
@@ -393,6 +402,7 @@ Activates, starts, or resumes an Instantly V2 campaign.
 
 | Parameter | Type | Required | Description |
 | --------- | ---- | -------- | ----------- |
+| `apiKey` | string | Yes | Instantly API key with the required V2 scopes |
 | `campaignId` | string | Yes | Campaign ID |
 
 #### Output
@@ -427,6 +437,7 @@ Pauses a running Instantly V2 campaign, stopping further email sends.
 
 | Parameter | Type | Required | Description |
 | --------- | ---- | -------- | ----------- |
+| `apiKey` | string | Yes | Instantly API key with the required V2 scopes |
 | `campaignId` | string | Yes | Campaign ID |
 
 #### Output
@@ -461,6 +472,7 @@ Permanently deletes an Instantly V2 campaign.
 
 | Parameter | Type | Required | Description |
 | --------- | ---- | -------- | ----------- |
+| `apiKey` | string | Yes | Instantly API key with the required V2 scopes |
 | `campaignId` | string | Yes | Campaign ID |
 
 #### Output
@@ -495,6 +507,7 @@ Retrieves Instantly V2 Unibox emails with search and pagination filters.
 
 | Parameter | Type | Required | Description |
 | --------- | ---- | -------- | ----------- |
+| `apiKey` | string | Yes | Instantly API key with the required V2 scopes |
 | `limit` | number | No | Number of emails to return, from 1 to 100 |
 | `starting_after` | string | No | Pagination cursor from next_starting_after |
 | `search` | string | No | Search query, email address, or thread:<thread-id> |
@@ -537,6 +550,7 @@ Sends an Instantly V2 reply to an existing Unibox email.
 
 | Parameter | Type | Required | Description |
 | --------- | ---- | -------- | ----------- |
+| `apiKey` | string | Yes | Instantly API key with the required V2 scopes |
 | `eaccount` | string | Yes | Connected email account used to send the reply |
 | `reply_to_uuid` | string | Yes | Email ID to reply to |
 | `subject` | string | Yes | Reply subject |
@@ -576,6 +590,7 @@ Retrieves Instantly V2 lead lists with search and pagination filters.
 
 | Parameter | Type | Required | Description |
 | --------- | ---- | -------- | ----------- |
+| `apiKey` | string | Yes | Instantly API key with the required V2 scopes |
 | `limit` | number | No | Number of lead lists to return, from 1 to 100 |
 | `starting_after` | string | No | Starting-after timestamp cursor |
 | `has_enrichment_task` | boolean | No | Filter by enrichment task setting |
@@ -613,6 +628,7 @@ Creates an Instantly V2 lead list.
 
 | Parameter | Type | Required | Description |
 | --------- | ---- | -------- | ----------- |
+| `apiKey` | string | Yes | Instantly API key with the required V2 scopes |
 | `name` | string | Yes | Lead list name |
 | `has_enrichment_task` | boolean | No | Whether this list runs enrichment for every added lead |
 | `owned_by` | string | No | User ID of the lead list owner |