Automations

Overview

An automation is a rule that acts on what Fencer finds instead of only sending a message. When its trigger fires and its conditions match, it can open an issue in Linear or Jira and notify your team. Automations live under Settings > Automations.

Prerequisites

Permissions: automations:read to view automations and automations:edit to change them. Among the built-in roles, only Administrator has them (see Permissions).
Ticket actions: a connected Linear or Jira integration.
Security detection trigger: a SIEM subscription.

How it works

When a trigger fires, Fencer checks every active automation on it. If the conditions match, Fencer records a run and carries out each action. An event that matches nothing leaves no run.

A rule is an automation when it has at least one ticket action. A rule whose only actions notify is a notification rule and is saved under Settings > Notifications; the editor warns “Notify-only rules are saved under Notifications, not Automations.”

An action never acts twice on the same vulnerability or detection, and a per-run cap limits how much one run files; matches above it are skipped and listed in the run log. Each issue an automation opens ends with a footer that names the automation and links to it.

Create an automation

Go to Settings > Automations and click New automation.
Pick a starter template or click Start from scratch.
Under When this happens, choose the Trigger and add conditions.
Under What to do, fill in the actions. A new automation opens on a ticket block for your connected tracker, or on a Notify block if none is connected. Click Add action to add a block, and use a block’s Action menu to change what it does.
Check the Matching preview: it shows matches from the last 14 days and what the automation would open, without opening anything. Click Preview to refresh it.
Enter a Rule name, or keep the suggested one, and click Save rule. The automation is active immediately.

In the list, use a rule’s toggle to pause it, and its menu to Edit, Duplicate (saved paused), or Delete it. Unlike notification rules, automations have no How often to send step and no Test send, because a test would open real issues.

Triggers

Ticket actions need a trigger that carries vulnerabilities or detections:

New vulnerability detected
Vulnerability status changed
Vulnerability SLA alert
Vulnerability deferral overdue
Security detection (SIEM)

Other triggers in the list, such as Task assigned, only offer Notify, so a rule on them is a notification. The digests and Plan limit reached are not offered. Changing the trigger removes actions it cannot run. See Triggers for what each one means.

Conditions

Leave the filters empty to match every occurrence. Otherwise:

Vulnerability triggers show Severity and Category as chips. Security detection shows Severity, Event Type, and Status.
Advanced conditions adds every other field, such as Asset, Assignee, SLA breached, or Tracked Externally, and Detection Rule for detections.
With more than one condition, a toggle switches between Match All and Match Any. Security detection always matches all conditions.

Actions

Create a ticket in Linear or Jira

Opens issues in your tracker for the matched vulnerabilities or detections.

Linear: Team (required), and optionally Project, Label, State, and Assignee.
Jira: Project (required), Issue type (Bug by default), and Assignee.
How to file: Grouped (the default) opens one issue per run listing every match; Per vulnerability opens one issue each.
More settings: Skip vulnerabilities that already have a Linear issue (or Jira issue) is on by default and also skips issues opened by hand. Max vulnerabilities per run is 25 by default, 1 to 100.
Assign to the vulnerability owner matches each owner to a tracker user, through your synced identities or by email. The person under Assignee becomes the Fallback assignee. Not offered for detections.
On Vulnerability SLA alert, each issue gets the SLA deadline as its due date.

For priority mapping and status sync, see Linear and Jira.

Notify

One Notify block per automation, with the destinations of a notification rule: Send Slack channel message, Send organization email, Webhook, Notify a user by email, Send Slack direct message, and Send an in-app notification. See organization rules, Slack, and Webhooks.

Starter templates

New automation offers three starters. Each seeds a ticket action for your connected tracker (Linear first if both are connected), skips vulnerabilities that already have an issue, and caps each run at 25. Without a tracker, the cards are disabled: “Connect an issue tracker to use this template.”

Critical and high vulnerabilities to an issue: New vulnerability detected where Severity is Critical or High, filed Grouped. Add an Asset condition to scope it to one repository.
Leaked secrets to an issue: New vulnerability detected where Category is Secret, filed Per vulnerability.
SLA breaches to an issue: Vulnerability SLA alert where SLA breached is Breached, filed Per vulnerability.

Run history and troubleshooting

Click Runs in the editor, or the history icon (View runs) on a rule in the list, to open its Run history, newest first. Each run shows a status such as Completed, Partial failure, or Failed. Expand it to see each action’s result and, for ticket actions, a Vulnerability, Result, Reason, and Issue table. Runs are kept for 90 days. A rule whose latest run failed or partly failed shows Needs attention in the list.

“Linear isn’t available, so rules that open a Linear issue won’t run.” (or Jira): the tracker is disconnected or broken, and ticket actions fail until you reconnect it with Connect Linear or Connect Jira.
No ticket action to choose: no tracker is connected, or the trigger has none (see Triggers).
Fewer issues than matches: check the Reason column, for example Already has an issue, Above the per-run cap, or Handled by an earlier run.
“Reconnect Linear for an improved Automations experience.”: reconnect so Linear shows the Fencer app, not the person who connected Linear, as the creator of the issues.
“You do not have permission to change automations.”: you can view automations, but changing them needs automations:edit.

Permissions

Ability	Grants
`automations:read`	The Automations tab, viewing a rule, and its run history.
`automations:edit`	Creating, editing, pausing, duplicating, deleting, and previewing rules.

Administrator holds both. Team Member, Read Only, and Penetration Tester hold neither, so the tab is hidden from them. In a custom role, Automations offers View and Edit: View adds Organization Settings View, and Edit adds Automations View and Organization Settings Edit. See Roles and Permissions.