Skip to main content

Automations (Workflows)

Overview​

Automations let you run versioned workflows on top of Attive’s unified data graph to monitor changes, generate insights, notify teams, and optionally write updates back to your connected systems (e.g., CRM).

A workflow is made of:

  • Triggers (optional): how the workflow starts (scheduled or event-based)
  • Inputs: parameters you provide at run time (or default values for scheduled runs)
  • Steps: the actions the workflow performs (queries, AI, notifications, CRM writes)

Workflows support draft vs published versions, and each execution produces a run with results and outputs.

Trigger behavior at a glance:

  • Scheduled (cron) workflows run on a schedule.
  • Event-triggered workflows run after Attive detects new records or watched property changes during ongoing data sync.

Resources​

Usage​

General usage​

  • Create or open a workflow in Automations.
  • Define inputs (the parameters you want the workflow to accept).
  • Add one or more steps to query data, extract insights, generate content, notify stakeholders, and/or update CRM.
  • Add triggers if you want the workflow to run automatically:
    • Schedule (cron): runs at set times
    • Event triggers: runs when records are created or when watched properties change
  • Publish when you’re ready to make it live. Draft changes don’t affect the published workflow until you publish again.

In-depth usage​

  • In-depth topic 1 (creating/configuring a workflow)

    • Define inputs to keep workflows reusable across accounts, deals, contacts, time ranges, etc.
    • Build steps so that structured data is produced early (query → extract), and messaging / updates happen after.
    • Use step-level conditions to keep the workflow from running actions when data doesn’t meet your criteria.

  • In-depth topic 2 (using workflows day-to-day)

    • Use scheduled workflows for recurring reporting (daily/weekly summaries).
    • Use event workflows to react to operational changes (new deals, lifecycle stage changes, risk signals).
    • Inspect workflow runs to understand what executed, what was skipped, and what outputs were produced.

Examples​

Example: Notify Slack on high-value new deals​

  • Trigger: New record on Deals with a condition like amount > 100000
  • Steps:
    • Query the graph to fetch the new deal’s context (account, owner, recent activity)
    • Extract key fields with AI into simple variables
    • Send a Slack message to the sales channel

Example: Weekly account health check​

  • Trigger: Cron (every Monday morning)
  • Steps:
    • Query accounts and recent signals
    • Summarize into a short report
    • Post to a Slack channel

Features​

FeatureWhat it does
Draft & published versionsSafely iterate in draft and publish when ready.
TriggersRun workflows on a schedule or in response to record events.
InputsParameterize workflows so they can be reused.
Step conditionsSkip steps when conditions aren’t met.
Dependency-aware executionSteps can depend on earlier steps; independent steps can run in parallel.
Targeted executionRun a specific step (and its dependencies) for faster iteration/debugging.
Run outputsWorkflows produce named outputs that can be used by later steps or returned from runs.
Slack notificationsSend messages to channels or users.
CRM updates/createsWrite workflow results back to CRM (single record or batch).
Schema-backed building blocksSteps and triggers are constrained to a supported catalog (see API reference).

API Reference​

This section lists the supported trigger and step types that can be used in workflow definitions.

Triggers​

cron​

  • What it does: Runs the workflow on a schedule.
  • Key fields:
    • id: string
    • type: "cron"
    • schedule: cron expression (e.g. "0 9 * * MON")
    • timezone (optional): defaults to "UTC"
  • Notes:
    • A cron trigger must be the only trigger in a workflow.
    • Scheduled runs rely on default input values for any required inputs.

event_new_record​

  • What it does: Runs when new records are created for an entity (optionally filtered by conditions).
  • Key fields:
    • id: string
    • type: "event_new_record"
    • entityName: entity name as it appears in the graph (e.g. "Contacts", "Deals")
    • conditions (optional): array of { property, operator, value }
    • logic (optional): "AND" | "OR" (default: "OR")
    • testRecordId (optional): record to use for test runs
  • Notes:
    • Multiple event triggers can be defined in one workflow.
    • In steps, you can reference the triggering record via {{trigger.<triggerId>.recordId}}.

event_property_change​

  • What it does: Runs when watched properties change on records (optionally filtered by conditions on the new value).
  • Key fields:
    • id: string
    • type: "event_property_change"
    • entityName: entity name as it appears in the graph
    • watchedProperties: string[] (only these properties are monitored)
    • conditions (optional): array of { property, operator, value } (property must be in watchedProperties)
    • logic (optional): "AND" | "OR" (default: "OR")
    • includeNewRecords (optional): boolean (also trigger on new records matching conditions)
    • testRecordId (optional): record to use for test runs
  • Notes:
    • Multiple event triggers can be defined in one workflow.
    • In steps, you can reference the triggering record via {{trigger.<triggerId>.recordId}}.

Steps​

All steps share these common fields:

  • id: string
  • name (optional): string
  • description (optional): string
  • needs (optional): string[] (step IDs this step depends on)
  • if (optional): condition expression (used to skip a step)
  • continueOnError (optional): boolean

query_graph​

  • What it does: Runs a Cypher query against the graph and returns a result output.
  • Key fields:
    • cypher: string
    • parameters (optional): record of query parameters
    • output: { name: string }

ai_extract​

  • What it does: Extracts structured fields from complex/unstructured data (often used to parse graph query results).
  • Key fields:
    • source: variable reference (or literal value)
    • prompt: string
    • outputs: array of named outputs (supports single values and typed lists)

ai_generate​

  • What it does: Generates text content from your inputs/previous step outputs.
  • Key fields:
    • prompt: string
    • systemPrompt (optional): string
    • temperature (optional): number
    • output: { name: string }

ai_summarize​

  • What it does: Summarizes a large value (often text-heavy) into concise text.
  • Key fields:
    • source: variable reference (or literal value)
    • instruction: string
    • output: { name: string }

slack_message​

  • What it does: Sends a message to Slack.
  • Key fields:
    • message: string
    • Provide exactly one of:
      • channel: string (e.g. "#sales-alerts")
      • userId: string (send a DM)

crm_update​

  • What it does: Updates fields on a single CRM record.
  • Key fields:
    • objectType: string (system name)
    • objectId: variable reference
    • fields: array of { key, value, updateIfEmpty? }
    • associations (optional): create/update primary associations

crm_create​

  • What it does: Creates a single CRM record.
  • Key fields:
    • objectType: string (system name)
    • fields: array of { key, value }
    • associations (optional)
    • output: { name: "recordId" }

crm_batch_create​

  • What it does: Creates many CRM records from a list produced earlier in the workflow.
  • Key fields:
    • objectType: string
    • source: variable reference to a list output
    • fields: array of { crmField, sourceField }
    • associations (optional): per-item associations via { targetObjectType, sourceField }
    • output: names for batch outputs (success/failure counts, created IDs, failed items)

crm_batch_update​

  • What it does: Updates many CRM records from a list produced earlier in the workflow.
  • Key fields:
    • objectType: string
    • source: variable reference to a list output
    • recordIdField: which list field contains the CRM record ID
    • fields: array of { crmField, sourceField }
    • associations (optional)
    • output: names for batch outputs (success/failure counts, updated IDs, failed items)

Supporting workflow APIs​

These endpoints support building, validating, and running workflows:

  • Workflow sync (/api/workflow/sync): used by the workflow editor to read/update draft definitions and to create/update/delete steps, inputs, and triggers.
  • Execute workflow (/api/workflow/execute): starts an on-demand workflow run.
  • CRM utilities (/api/workflow/crm-utils): search CRM objects and fields to help configure CRM steps.
  • Entity fields (/api/workflow/entity-fields): returns the available fields for a graph entity backed by an integration connector.