Coevera

Archives a set of leads. This is a business operation, not a plain is_archived flag update — it triggers server-side logic: AI fitness indicator snapshot, timeframe-in-step tracking, approval removal, optional memo creation, and task completion. Key differences from bulk_archive_opportunities: • entity_fields is optional. When omitted, all validations are skipped entirely. When provided, conditional field requirements are enforced. • Activity completion (complete_activity_ids) is scoped to Tasks only — appointments and other activity types are not affected. • No quote archiving — leads do not own quotes. • No recurrence spawn — leads have no recurrence configuration. Async behaviour: batches of 20 or more leads are processed asynchronously via a background job. In that case the response includes an asyncOperationId to track progress. lead_ids: IDs of the leads to archive. entity_fields: Optional dict of field api_name→value to apply before archiving (e.g. {"reason_of_close_id": "..."}). memo_text: Optional text for a Memo linked to each lead. complete_activity_ids: Optional list of task IDs to mark as completed (Tasks only). rollback_method: ROLLBACK_ALL (default) or ROLLBACK_FAILED.

bulk_archive_leads

Archives a set of opportunities. This is a business operation, not a plain is_archived flag update — it triggers server-side logic: AI fitness indicator snapshot, approval removal, optional memo creation, activity completion, and quote archiving (transitions linked quotes to Lost). Important side effect: if an opportunity has a recurrence configured with a Lost condition, archiving may spawn a new copy of the opportunity at the recurrence step with a computed next closing date. Unlike bulk_move_opportunities, archiving cannot accept quotes — only archive them. Async behaviour: batches of 20 or more opportunities are processed asynchronously via a background job. In that case the response includes an asyncOperationId to track progress. opportunity_ids: IDs of the opportunities to archive. entity_fields: Optional dict of field api_name→value to apply before archiving (e.g. {"reason_of_close_id": "...", "closing_date": "2024-12-31"}). memo_text: Optional text for a Memo linked to each opportunity. complete_activity_ids: Optional list of activity IDs to mark as completed. archive_quote_ids: Optional list of quote IDs to transition to Lost status. rollback_method: ROLLBACK_ALL (default) or ROLLBACK_FAILED.

bulk_archive_opportunities

Moves a set of opportunities to a new pipeline step. This is a business operation, not a plain field update — it triggers server-side logic: timeframe-in-step tracking, optional memo creation, activity completion, and quote status transitions. Constraints: • The target step must belong to the same pipeline as each opportunity; cross-pipeline moves are not allowed (use changePipeline instead). • Moving backward (lower sort order) skips validation; moving forward runs full validation including conditional field requirements. • The target step may have checklist requirements (mandatory fields, linked activities, documents) configured by the pipeline admin. These are enforced server-side on move; if any required items are unmet, individual records will fail validation. • An opportunity with a pending approval is move-locked and cannot be moved until the approval is resolved; this operation does not remove approvals. Async behaviour: batches of 20 or more opportunities are processed asynchronously via a background job. In that case the response includes an asyncOperationId to track progress. opportunity_ids: IDs of the opportunities to move. step_id: ID of the destination pipeline step. memo_text: Optional text for a Memo linked to each opportunity. complete_activity_ids: Optional list of activity IDs to mark as completed on each opportunity. accept_quote_ids: Optional list of quote IDs to transition to Accepted status. archive_quote_ids: Optional list of quote IDs to transition to Lost status. rollback_method: ROLLBACK_ALL (default) or ROLLBACK_FAILED — controls whether a per-opportunity failure aborts the entire batch (ROLLBACK_ALL) or only that record (ROLLBACK_FAILED).

bulk_move_opportunities

Converts a set of leads into opportunities. This is a destructive entity-type promotion — each Lead is physically deleted from the database and replaced by a new Opportunity that shares the same primary key. What happens server-side per lead: • Common fields are copied from Lead to Opportunity (skipping non-applicable fields like reason_of_close). • The target step is set from step_id; any additional opportunity_fields are merged in. • Both the Lead's step checklist and the Opportunity's target-step checklist are enforced. • The resulting Opportunity is flagged was_qualified=True (permanent audit marker used by changelog). • Active email sequences are re-pointed from the lead ID to the opportunity ID. Choosing the right step_id: A Step entity belongs either to a Lead Process (has lead_process_id) or an Opportunity Pipeline (has pipeline_id). Only steps with pipeline_id are valid targets for qualification — steps with lead_process_id are lead-only and will cause a 'Cannot qualify lead to lead process step' error. The final (Won) step of a pipeline is also rejected. Use search_records on Step with fields=['id','name','pipeline_id','lead_process_id'] to identify the correct step before calling this tool. Validation — qualification runs full Opportunity validation: Required Opportunity fields and required relations must be satisfied either on the source Lead already or via opportunity_fields. Common failures: • closingDate missing — pass it in opportunity_fields as {"closingDate": "YYYY-MM-DD"}. • No primary account relation — create a LeadOpptyAccountRelation with is_primary=true on the lead before qualifying, or the pipeline step's checklist may block qualification. • Step checklist requirements — inspect the step's checklist fields if validation errors persist. opportunity_fields field names: Keys must use the GraphQL/API camelCase names, NOT the CRM schema snake_case names. Correct: {"closingDate": "2026-12-31", "ownerId": "<uuid>"} Incorrect: {"closing_date": "2026-12-31", "owner_id": "<uuid>"} No async chunking: all leads are converted synchronously regardless of batch size. lead_ids: IDs of the leads to qualify. step_id: ID of the target Opportunity pipeline step (must have pipeline_id, not lead_process_id). opportunity_fields: Optional dict of additional camelCase field name→value pairs for the resulting opportunities (e.g. {"closingDate": "2026-12-31"}). Do not include stepId here. rollback_method: ROLLBACK_ALL or ROLLBACK_FAILED. Note: the BulkQualifyLead mutation has no server-side default — omit to let the server decide.

bulk_qualify_leads

Unified ownership reassignment across supported CRM entity types. Supported entities and their dispatch path: • Task → changeOwnershipTask GraphQL mutation (per record, sequential). Requires unit_id. • Opportunity → changeOwnershipOpportunity GraphQL mutation (per record, sequential). Requires unit_id. • Contact, Account, Appointment → plain owner_id update via REST. unit_id is optional. • Lead, Memo → plain owner_id update via REST. unit_id is optional. Warning: after reassignment the service account loses write and ownership permissions on these records and cannot self-revert. • All other entity types → unsupported error, no CRM call is made. Returns a list with one entry per record: {"id": "...", "url": "..."} on success {"id": "...", "error": "..."} on per-record failure (mutation path) {"id": "...", "url": "...", "warning": "..."} for Lead/Memo transfers entity_name: CRM entity type to reassign (e.g. 'Opportunity', 'Task', 'Contact'). record_ids: UUIDs of the records to reassign. Must not be empty. owner_id: UUID of the new owner (Client entity). unit_id: UUID of the new sales unit. Required for Task and Opportunity. (SalesUnit entity) options: Entity-specific flags. Unknown keys are silently ignored; missing keys default to False. keep_owner_as_editor (Task, Opportunity) — keep the displaced owner as a sharing Editor. transfer_linked_records (Opportunity) — cascade-reassign linked records owned by the displaced owner.

change_ownership

Records that a step checklist requirement has been satisfied for a specific opportunity, lead, or quote by creating a LeadOpptyStepCheckListRelation record. Each checklist item type requires different evidence — supply the matching ID field: Default / CreateInfluenceMap — set item_checked=true (no evidence ID needed) ActivityType — supply activity_id pointing to an existing Task or Appointment of the type the checklist item requires CreateNote — supply note_id pointing to an existing Note linked to the record AttachDocument / UseDocumentTemplate — supply cloud_object_id pointing to an uploaded document SendEmail — supply email_id pointing to a sent Email FieldType — no relation record needed; set the field value directly on the Opportunity via update_records instead step_checklist_id: UUID of the StepChecklist item being satisfied. lead_oppty_id: UUID of the Opportunity or Lead. Mutually exclusive with quote_id. quote_id: UUID of the Quote. Mutually exclusive with lead_oppty_id. item_checked: Set to true for Default-type items that have no linked evidence. activity_id: UUID of the Task or Appointment that satisfies an ActivityType item. note_id: UUID of the Note that satisfies a CreateNote item. cloud_object_id: UUID of the uploaded document for AttachDocument / UseDocumentTemplate items. email_id: UUID of the sent Email for SendEmail items.

complete_step_checklist_item

Creates one or more records in a Coevera CRM entity. Each record is a dict of field api_name → value pairs. Returns a result list in the same order as the input: each entry is either {"id": "...", "url": "..."} on success or an error object with a "code" field on failure. Invoke to add new records to the CRM.

create_records

Returns identity information for the authenticated user: connected Pipeliner space (space_id), user ID, granted OAuth scopes, OAuth client ID, token expiry, and resource audience. Invoke when user identity, connected space, or OAuth permissions need to be determined.

me

Returns the field schema for a named Coevera CRM entity. The response includes entity metadata and a `fields` array. Each field entry contains: api_name, label, data type, required (bool), read_only (bool), filterable (bool) default_value, and — for dropdown fields — an `options` list of allowed values. Composite fields include a `composite_field` descriptor. Invoke when field names, types, or constraints are needed to construct a search filter or a create/update payload.

meta_describe_entity

Fetches records by ID from a Coevera CRM entity. Returns {entity, count, records} where records is the full list of matching records in the same order as record_ids (records not found in the CRM are simply absent). fields: list of field api_names to include in each record. expand (optional): list of field api_names to expand as nested objects. Only supported for relation fields. Invoke when specific record IDs are already known and their field values are needed.

get_records