Team workflow destinations
Deliver signed, scoped Veriom events to Slack, Jira automation, SIEM collectors, policy engines, and generic webhooks.
Workspace Owners and Admins configure team destinations in Settings → Automation. Each destination selects an explicit event allowlist. Veriom queues only matching events and retains delivery status, retry history, and the configuration audit trail.
Destination types
| Type | Delivery shape | Typical use |
|---|---|---|
| Slack | Incoming-webhook text and Block Kit fields | Review-ready audit and remediation notifications |
| Jira | Jira automation envelope with a nested Veriom event | Ticket rules and ownership routing |
| SIEM | Structured timestamp, event action, organization, and Veriom envelope | Security operations correlation |
| Policy | Versioned policy-event envelope | External deterministic decision systems |
| Webhook | Stable Veriom event envelope | Customer-built automation |
Integrity and replay
Every request includes delivery, event, timestamp, and HMAC-SHA256 signature headers. The signing secret is generated when the destination is created, encrypted at rest, and shown once. Destinations must use HTTPS and resolve only to public addresses. Redirects are disabled, and production egress controls remain the SSRF backstop.
Delivery failures use bounded exponential retry. Operators can see metadata-only health across the integration fleet; they cannot see signing secrets or customer payloads.
Action boundary
These integrations deliver events. They do not give an agent ambient permission to create tickets, post arbitrary messages, change policy, or modify a workspace. Consequential operations use authorized workflow actions: capability-specific grants for Jira ticket creation, internal ownership routing, and Owner-approved policy exceptions, each with a separate requester and approver.
Configuration creation, updates, disables, manual delivery retries, and policy changes create audit events.