Skip to main content

Automation design practices

This guide is a practical checklist for designing high-quality Automations (Workflows) in Attive. It’s based on the workflow-creation guidance used by Attive’s automation designer.

Core principles​

  • Design for reusability: use inputs instead of hardcoding IDs, names, thresholds, or dates.
  • Make data → meaning → action explicit: separate steps that fetch data, shape it into a usable form, and take action.
  • Prefer deterministic logic for deterministic problems: use graph queries for filtering, counting, grouping, and aggregation.
  • Use AI for language and extraction, not math: AI is great at summarizing and extracting; it is not the best tool for aggregations.

A reliable workflow usually follows this pattern:

  1. Extraction: query the graph to retrieve the specific records you need.
  2. Transformation: turn raw/complex results into a few named variables you can reliably reuse.
  3. Action: send messages, generate a report, or write updates back to your CRM.

Why this works:

  • Query results can be complex and nested.
  • Later steps work best when they read simple variables (a few strings/numbers/booleans) rather than large raw objects.

Working with data: “query first”​

Use graph queries for aggregation​

If you need totals, breakdowns, trends, or thresholds, compute them in the query step.

  • Good: count deals by stage, sum pipeline by owner, filter to “last 7 days,” compute top-N.
  • Avoid: pulling a huge list and asking AI to count/sum/group.

Split “stats” and “list” into separate queries​

If you need both:

  • a list of items (for inspection or summarization), and
  • statistics (counts, sums, grouped metrics)

create two separate queries:

  • one query optimized for stats,
  • one query optimized for a manageable list.

This keeps workflows fast, predictable, and easier to evolve.

Choosing the right AI step​

ai_extract: turn complex data into simple variables​

Use when you need a small set of named outputs you’ll reuse later (e.g., deal name, owner, a computed classification).

  • Best for: pulling specific fields from query results, parsing text into structured outputs.
  • Not for: counting, grouping, or other aggregations.

ai_summarize: condense large, text-heavy results​

Use when your query returns a lot of text (transcripts, notes, long descriptions) and you want a short, readable summary.

  • Best for: “give me the key themes,” “what changed,” “top risks,” “next actions.”
  • Not for: aggregation.

ai_generate: write the final report/message body​

Use when you want polished narrative output (e.g., an executive summary, customer update, internal brief) based on earlier extracted variables.

Tip: Treat this as a final formatting / synthesis step, not a data processing step.

Designing actions (Slack + CRM)​

Slack messages​

  • Prefer messages that are actionable: what happened, why it matters, what to do next.
  • Include context (account/deal/contact name) and at least one useful next step.

CRM writes​

  • Only write to CRM after you’ve extracted the exact fields you need.
  • Be explicit about when updates should happen (use step conditions).
  • When updating lists of records, produce a structured list first, then use batch steps.

Guardrails: conditions, skipping, and safe failure​

Use step conditions to avoid noisy actions​

If a workflow can run frequently (especially event triggers), use conditions to prevent spam:

  • Only notify when a threshold is met.
  • Only write to CRM when required fields are present.
  • Skip “nice-to-have” steps when upstream data is missing.

Decide what should happen on error​

Some steps are critical (e.g., fetching data); others are optional (e.g., a Slack notification). Configure workflows so failures behave the way you’d expect in production.

Trigger design​

Scheduled workflows (cron)​

Use when you want recurring reporting or periodic checks.

  • Ensure required inputs have sensible defaults.
  • Prefer schedules for “rollups” (daily/weekly summaries).

Event workflows​

Use when you want near-real-time responses to changes.

  • New record triggers are best for onboarding and “react to creation” patterns.
  • Property change triggers are best when you care about changes to specific fields.
  • Keep the watched properties focused to reduce noise.

Anti-patterns to avoid​

  • Using AI to count/sum/group when a query can compute it.
  • One huge query that returns everything “just in case.”
  • Passing raw, massive results into AI steps without summarizing or filtering first.
  • Hardcoded IDs and constants that make the workflow non-reusable.
  • Always-on notifications with no conditions (Slack spam).

Review checklist (before you publish)​

  • Inputs: Are hardcoded values converted into reusable inputs?
  • Data shape: Are later steps consuming simple, named outputs (not raw blobs)?
  • Aggregation: Are counts/sums/grouping done in queries, not AI?
  • Triggers: Do triggers match the intended behavior (schedule vs event)?
  • Noise control: Are there conditions to prevent unnecessary actions?
  • Action clarity: Do Slack/CRM steps clearly communicate or update what matters?
  • Maintainability: Are step IDs and descriptions clear enough for someone else to edit later?