Event-Driven Automations on Evercore

Publish workflow graphs triggered by system actions—upload confirmed, share opened, export ready—with toolkit nodes, Composio Gmail/Slack steps, live runs, and automation.run.* events.

Automations react to Evercore system actions—upload confirmed, share viewed, export sealed—and execute a published node graph with toolkit steps, filters, and Composio integrations. Trigger payloads surface as {{trigger.data.*}} in every node.

React to Evercore events with governed, publishable graphs.

Automations start on system actions—upload confirmed, share opened, compliance export ready—and run a versioned node graph with toolkit steps, filters, and connector handoffs. The same webhook payload becomes {{trigger.data.*}} for every downstream node.

Value

Event-native triggers

Pick from the platform event catalog (files, versions, shares, trace, automations lifecycle). Filters narrow which deliveries enqueue a run.

Toolkit graph

Compose triggers, data transforms, flow control, Evercore API calls, and Composio integrations (Gmail, Slack, Teams) with schema-validated node configs.

Auditable runs

Dry-run and live runs persist steps_log, expose live feeds, and emit automation.run.* events for SIEM and connector pipelines.

How it works

Choose a system action

List catalog/actions and pick upload.completed, share.opened, or export-ready events.

Compose the toolkit graph

Add transforms, API nodes, and Composio integrations with schema-validated configs.

Validate and publish

Dry-run with sample payloads, then publish a version—filters decide which deliveries enqueue runs.

Operate with live feeds

Monitor runs, issue cancel links, and fan out automation.run.* events to connectors.

Use cases

Legal & finance ops

Notify deal teams when external reviewers open shares or when export packs seal—without a second orchestration SKU.

Supply chain & logistics

Fan out connector events when manifests confirm on Arweave so ERP and WMS stay aligned.

Platform engineering

Replace shadow scripts with scoped automations:write keys, publish gates, and replayable run history.

Security guarantees

Scoped automation keys

Separate builder and operator keys with automations:read and automations:write—no blanket admin scopes.

Aligned event vocabulary

Triggers use the same event ids as webhook deliveries—reducing schema drift between docs and runtime.

Durable run evidence

steps_log, live feeds, and lifecycle events support audits longer than chat notifications.

For operators

  • Grant automations:read and automations:write scopes on dedicated API keys for builders vs operators.
  • Draft in Console, validate the graph, publish a version, then rely on system_action triggers—no cron required.
  • Use GET /automations/catalog/actions and /catalog/node-types to keep Console and API clients aligned with the runtime.

For buyers

  • Turn confirmation and governance signals into operational playbooks without maintaining a second orchestration product.
  • Keep integration logic inside the same trust layer that already stores ciphertext and proof receipts.
  • Demonstrate who ran what: run history, cancel links, and signed outbound events survive longer than chat transcripts.

How do I reference trigger fields in nodes?

Use {{trigger.data.fieldName}}—the same data object documented for webhook POST bodies.

Can I run a graph manually?

Yes. POST /automations/:id/manual-run enqueues a run with a sample or production payload for testing.