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.