figma guide
Designing security automation and response workflows UI in Figma: triggers, actions, and handoff
Design security automation and response workflow UI in Figma with trigger builders, action steps, approval gates, run history, and Dev Mode specs for enterprise Security SOAR admin.
- Published
- Updated
- Jul 23, 2026
- Read time
- 7 min
- Level
- Intermediate
Quick answer
Security automation UI lets teams define if-this-then-that playbooks with human approval gates—not run unchecked scripts on production accounts. Design a workflow catalog with trigger, status, last run, and owner; visual workflow builder with triggers, conditions, actions, and branches; approval steps for destructive actions; run history with step-level logs; dry-run mode for staging; and integration tiles linking to alerting, incident runbooks, and session management. Start from the Figma guides hub and pair with suspicious login, PAM, API keys, audit log, and Dev Mode handoff.
Who this is for
- Product designers building SOAR-style workflow editors, run consoles, and approval queues for enterprise Security and IT admin consoles.
- Design system teams aligning step nodes with progress steppers, modals, and toasts.
- Engineers implementing trigger webhooks, idempotent actions, rollback paths, and audit emission for every automated step.
Workflow catalog (admin hub)
WorkflowCatalog
├── Header: Security automation · [ New workflow ] [ Run history ] [ Integrations ]
├── Summary: 16 active · 4 awaiting approval · 89 runs last 24h · 2 failed
├── Filters: Trigger type · Status · Owner · Risk level
└── Row: Lock account on impossible travel · Alert-triggered · Active · Last run 2h ago| Column | Content |
|---|---|
| Workflow name | ”Revoke sessions on credential leak” |
| Trigger | Alert fired, Schedule, Manual, Webhook, Audit event |
| Risk level | Low / Medium / High / Destructive |
| Status | Active / Paused / Draft / Error |
| Approval required | Yes/No chip for destructive paths |
| Last run | Success / Failed / Awaiting approval |
| Owner | Security automation team |
| Linked playbook | Deep link to incident runbook |
Verdict: catalog separates read-only enrichment workflows from account-impacting ones—destructive rows use warning styling.
Workflow builder (visual editor)
WorkflowBuilder
├── Trigger: Alert "Impossible travel login" · Critical
├── Condition: User role ≠ Break-glass account
├── Step 1: Enrich — Fetch [sessions](/designing-active-sessions-and-device-management-ui-in-figma/) + geo
├── Step 2: Notify — Slack #security-incidents with summary
├── Step 3: Approval gate — Security on-call (5m timeout → skip)
├── Step 4: Action — Revoke all sessions · Lock account 24h
├── Step 5: Audit — Write [audit event](/designing-audit-log-and-security-activity-ui-in-figma/) + open ticket
└── On failure: Rollback lock · Page on-call · Link runbook| Node type | Examples |
|---|---|
| Trigger | Alert rule fired, cron, manual button, inbound webhook |
| Condition | Role, env, severity, allowlist match, duplicate run check |
| Enrichment | Lookup user, IP reputation, past alerts, vendor risk score |
| Action | Revoke session, rotate API key, disable OAuth app, tag resource |
| Approval | Human confirm with timeout and escalation |
| Branch | If false positive rate high → tune rule instead |
| Notify | Slack, email, PagerDuty—reuse alert routing channels |
Use canvas nodes with cards for steps; sidebar inspector for config.
Dry-run: “Simulate on alert #8842” shows which steps would execute without side effects—required before enabling destructive workflows.
Approval gates and human-in-the-loop
ApprovalQueue
├── Pending: Revoke all sessions · jchen@acme.com · Triggered by impossible travel
├── Context: 2 active sessions · Last login Seattle 28m ago · New login São Paulo
├── Workflow: Lock account on impossible travel · Step 3 of 5
├── Actions: [ Approve ] [ Deny ] [ Approve with modification ]
└── SLA: Auto-deny in 4m · Escalate to secondary on-call| Pattern | UI detail |
|---|---|
| Approval modal | Full context: alert, user, proposed actions, rollback plan |
| Modification | Approve session revoke only—skip account lock |
| Timeout | Countdown; default deny or escalate per workflow setting |
| Audit trail | Approver identity, timestamp, decision reason |
| Break-glass bypass | Emergency access accounts excluded from auto-lock |
Destructive actions (delete data, org-wide disable) require two-person approval—show second approver queue.
Link team roles—only Security Responder+ can approve High/Destructive steps.
Run history and step logs
RunDetail
├── Workflow: Lock account on impossible travel · Run #4521 · Completed
├── Trigger: Alert #8842 · 3:15 PM · Duration 4m 12s
├── Steps:
│ ├── ✓ Enrich sessions — 2 found
│ ├── ✓ Notify Slack — delivered
│ ├── ✓ Approval — Ana Liu approved 3:17 PM
│ ├── ✓ Revoke sessions — 2 revoked
│ └── ✓ Audit write — event_id ae_991
├── Rollback available: No (sessions already revoked)
└── [ Re-run from step 2 ] [ Export log ]| Log field | Purpose |
|---|---|
| Step status | Success, skipped, failed, awaiting approval |
| Input/output | Redacted JSON for debugging |
| External call ID | Slack ts, ticket ID, webhook delivery_id |
| Error detail | Retry count, next retry at |
| Correlation ID | Links alert, run, and audit events |
Use tables for run list; expandable rows for step logs.
Re-run guard: destructive workflows require new approval unless “retry failed step only” within 15m window.
Integration tiles
IntegrationsHub
├── Slack — Connected · Post message, request approval
├── PagerDuty — Connected · Create incident
├── Jira — Connected · Create ticket with template
├── Custom webhook — [Configure](/designing-webhooks-and-event-subscriptions-ui-in-figma/)
└── SIEM — Forward enriched event · Link ingestion| Integration | Typical actions |
|---|---|
| Chat | Notify channel, interactive approve/deny buttons |
| Ticketing | Create INC with alert + run context pre-filled |
| Identity | Revoke session, force MFA, disable user |
| Secrets | Trigger rotation on leak alert |
| SIEM | Push enrichment back to index |
Show connection health badge—failed OAuth refresh blocks workflow save with clear fix path.
Prebuilt workflow templates
| Template | Trigger | Risk | Pairs with |
|---|---|---|---|
| Impossible travel response | Critical auth alert | High | Suspicious login |
| Leaked API key rotation | DLP or scanner alert | High | API keys, vault |
| Bulk failed admin login | High auth alert | Medium | IP allowlist tune |
| JIT elevation expiry reminder | Schedule | Low | PAM policies |
| New risky OAuth app | Medium app alert | Medium | App approvals |
| Compliance export completion notify | Job success webhook | Low | GRC team |
| SCIM sync failure escalate | Ingestion alert | Medium | Directory admin |
Template gallery uses cards with risk badge and “Customize before enable.”
Posture and automation hygiene
Feed into security posture dashboard:
PostureGapCard — Automation hygiene
├── 2 destructive workflows without approval gate
├── 12% of runs failed at external integration (Slack rate limit)
├── Mean approval time: 6m (target: 5m for Critical)
└── [ Review workflows ] [ Open run analytics ]Analytics: runs by outcome, top failing steps, approval SLA trend—filter by workflow and trigger type.
Pair with incident runbooks—manual runbook steps can link “Automate this” to spawn workflow draft.
Common mistakes
| Mistake | Why it hurts | Fix |
|---|---|---|
| Auto-lock without approval | False positive locks exec during travel | Approval gate + break-glass exclude |
| No dry-run | First production run breaks accounts | Simulate on historical alert |
| Missing rollback path | Partial failure leaves inconsistent state | Define rollback per destructive step |
| No idempotency | Duplicate alert double-revokes | Dedupe key on trigger + subject |
| Secrets in workflow JSON | Leak in run log export | Vault references for action credentials |
| Approval timeout silent | Action never runs; alert stale | Explicit deny or escalate UI |
| No step-level audit | Cannot prove SOC2 response | Audit write as required final step |
| Over-automation early | Team skips runbooks | Start with notify-only workflows |
| Integration failure unhandled | Workflow stuck “running” | Retry policy + fail state with notify |
| Same workflow prod and sandbox | Test lock hits real user | Environment condition on trigger |
Recommended workflow
- Design workflow catalog with trigger, risk, approval, and last-run columns.
- Build visual editor with triggers, conditions, actions, branches, and failure handlers.
- Add approval queue with context modal, modification, timeout, and dual approval for destructive.
- Create run history with step logs, correlation IDs, and selective re-run.
- Wire integration hub with health status and OAuth refresh errors.
- Offer template gallery linked to alert rules and runbooks.
- Surface hygiene on posture dashboard; annotate action payloads in Dev Mode.
FAQ
SOAR vs incident runbooks?
Runbooks guide humans step-by-step; automation executes approved actions. Link them—runbook step “Run workflow X” with manual fallback.
Can workflows modify team roles?
Rarely—require Destructive risk + dual approval; most workflows notify rather than change RBAC.
Member-visible automation?
No silent locks—pair auto-lock with suspicious login member email and recovery path.
Workflow triggered from SIEM ingestion?
Yes—webhook trigger on normalized event type; show parser field mapping in trigger config.
Compliance retention for run logs?
Align with data retention—typically 1–7 years for destructive runs; include in compliance export.
Next steps
- Design security alerting rules and notification routing UI in Figma — primary trigger source for automation
- Design incident response runbooks and security playbooks UI in Figma — human companion to automated steps
- Design suspicious login alerts and account recovery UI in Figma — member-facing outcome of auth automation
- Design SIEM log ingestion and data source connectors UI in Figma — event triggers from normalized logs
- Design privileged access management and JIT access UI in Figma — elevation workflows and expiry automation
§ Keep reading