If the on-call schedule changes at the last minute, does the workflow still page the right person?

It reads the current on-call assignment from your rotation source at the moment it pages, not a static contact list saved when the workflow was built — so a shift swap the night before doesn't send a 2am page to someone who's off.

What stops an SLA clock from penalizing an agent for a delay the customer caused?

Tickets in a 'waiting on customer' or paused status are excluded from the elapsed-time calculation. The clock only runs while the ticket is actually sitting in the agent's queue, so a customer who goes quiet for two days doesn't burn the agent's SLA.

Can a runbook step call an internal API, or is this just a checklist with extra formatting?

Each documented step maps to an actual HTTP call against your internal or vendor API, and the response is recorded in the run log. A step that returns an error halts the run and pings the runbook owner — it doesn't silently continue to step 8 assuming step 7 worked.

How does a handoff know which board and owner to create the item in?

A routing table keyed by status change and source team decides the destination — a Jira ticket marked 'ready for QA' lands in the QA board with the right owner, not a shared inbox someone has to triage. The table lives on the canvas, so an ops lead can edit it without filing an engineering request.

What happens when a handoff or incident can't be routed automatically — a new team, a service with no owner on file?

It doesn't get dropped in a random column or paged to whoever's online. The item is held and flagged in Slack for a human to route, so a gap in the routing table becomes a five-second decision instead of a lost handoff.

Which workflow should an operations team build first?

Start with whichever one is currently a spreadsheet or a person's memory — usually incident paging or SLA tracking, since both need a routing table or a rotation source connected before the second workflow (handoffs, runbooks) can reuse it.

FOR OPERATIONS TEAMS

Run the business without running in circles

Handoffs, incidents, and SLAs live in five tools and three channels. WEXTL connects them on a canvas everyone can read — so work moves forward with a log, not a scavenger hunt.

Browse templates

Deploys this workflow into your workspace — you'll connect your own accounts.

Workflow moving tasks from Asana to Monday with Slack notification

GDPR
Data Encryption
2FA
Local Data Region

5: tools a handoff passes through before it's done

20 min: confirming who's on call before touching a SEV1

90%: SLA elapsed before it pages the manager

* Illustrative example, not measured customer data.

Clean handoffsWhen a task is ready, the next team gets context in their tool — automatically.

Incident coordinationSeverity rules open the war room, create tasks, and post status — same playbook every time.

SLA visibilityBreaches ping the channel before customers notice; every ticket row is logged.

Runbooks that executeTurn Notion runbooks into steps that call APIs and confirm in Slack.

Operations patterns on one canvas

Cross-team handoffs with context

When work is ready in one board, create the item in the next tool and notify the owner.

Trigger — a work item's status changes to a hand-off state in the source tool (a Jira issue moves to Done, an Asana task is checked complete).
Information collected — item title, description, checklist/subtask state, attachments, requester, and any priority or severity tag already on it.
Connected applications — Jira or Asana as the source board, Monday.com or Trello as the receiving team's board, Slack for the handoff notification.
Decision logic — matched against a routing table keyed by status-change and source team, so a 'ready for QA' ticket lands on the QA board with the right owner, not a shared inbox.
AI step — drafts a handoff summary from the ticket's comment history so the receiving team isn't re-reading twenty comments to find the one that matters.
Human approval — only handoffs flagged 'needs context call' wait for a person; everything the routing table resolves creates the downstream item automatically.
Actions — creates the item in the destination tool with the summary attached, links back to the source ticket, and notifies the owner in Slack.
Exception handling — when the routing table can't resolve a destination board or owner, the item is held and flagged in Slack instead of being dropped into a random column.

Workflow moving tasks from Asana to Monday with Slack notification

What operations actually fights all day

None of this is complicated work. It's coordination overhead, multiplied by however many tools the org runs on. Handoffs live in five tools and three channels, and 'done' in one tool doesn't mean anything in the next until someone notices and re-types it.

An alert fires and the first 20 minutes go to confirming who's actually on call tonight, not to fixing anything. A ticket sits three days past its SLA warning in a shared inbox nobody individually owns. A runbook exists as a Confluence page with eleven steps, and step 7 has been wrong since the last migration — nobody finds out until someone runs it live during an outage.

Step 1
The first 20 minutes of an incident
Spent confirming who's paged and where to post, before anyone touches the actual problem.
Step 2
SLA clocks nobody's watching
A ticket ages past its warning threshold in a shared inbox no single person owns.
Step 3
Runbooks that drift from reality
A documented step stops matching production, and nobody finds out until it's run live.

None of it needs a hero. All of it needs a system that doesn't forget what the rule was.

Example: automate incident response

A concrete run, start to finish — the kind of incident workflow an ops or SRE lead clones from the template library and tunes to their own severity levels and rotation.

Trigger: a monitored alert crosses a severity threshold, or a responder declares an incident manually from a Slack command.

WEXTL checks: which service is affected, saved severity criteria for that service, the current on-call rotation (not a static contact list), and whether an incident with this fingerprint is already open.

Human judgment

Whether the outage is bad enough to notify executives, what the status page actually says, and when it's safe to call it resolved stay human calls. The workflow pages the right names and proposes the update — it doesn't decide the outage is over.

Step 1

1. Alert fires or is declared

A monitoring alert or a manual Slack command starts the run.

Step 2

2. Classify severity

Matched against saved criteria for that service — outage vs. degraded tool aren't the same trigger.

Step 3

3. Page the right on-call and open the war room

Pulls the live rotation assignment, not a list saved when the workflow was built, and creates a dedicated channel with the incident ID in the title — from the same trigger.

Step 4

4. Draft the status update

AI drafts customer-facing language from the alert payload for review.

Step 5

5. Hold for approval

External status language waits for the on-call lead before it posts.

Step 6

6. Create follow-up tasks, escalate, and log

One task per affected component owner; no acknowledgment inside the configured window pages the secondary on-call automatically; every page, post, and task creation is timestamped for the postmortem.

A scheduled check reads open tickets against their assigned SLA policy.

Elapsed time compared against the threshold for that priority tier — tickets marked 'waiting on customer' don't burn the clock while they're paused.

At 75% elapsed, a Slack DM goes to the assigned agent — not yet the manager.

At 90% elapsed with no update, the manager gets pinged with the ticket link.

Every check writes a row — ticket ID, elapsed percentage, action taken — and once the ticket is updated, escalation stops and the resolution time is logged.

The log feeds the Monday SLA review without anyone exporting a CSV.

Example: automate SLA breach escalation

The same logic, applied to a ticket queue instead of an alert: watch the clock, escalate on schedule, and leave a record a manager can trust without opening every ticket.

Trigger: a scheduled check reads open tickets against the SLA policy attached to each one.

Fields compared: ticket priority tier, elapsed time since open, current status (active vs. paused), and the threshold defined for that policy.

Human judgment

The workflow watches the clock and escalates; it doesn't reprioritize the queue or reply to the customer for the agent. Which ticket gets worked next, and what gets said, stay with the person who owns it.

Who operations workflow automation is for

Not every ops role needs this on day one. It's built for the parts of the job that repeat across a lot of incidents, a lot of tickets, or a lot of tools that don't talk to each other.

IT/Service Operations Managers
— Running handoffs across support, engineering, and PM boards that don't share a status field.
On-call engineers and SRE leads
— Standardizing incident response across more than one severity tier and rotation.
Support Operations leads
— Accountable for SLA compliance across ticket queues with different policies per tier.
Business/RevOps teams
— Coordinating handoffs between departments that don't share a single system of record.
Ops teams maintaining runbooks
— Documentation that needs to actually execute, not just describe steps someone might follow.
Teams running a shared on-call rotation
— Across more than one tool, where a static contact list goes stale within a quarter.

WEXTL is not trying to replace the on-call engineer or the ops lead — it handles the paging, routing, and logging so a judgment call gets a person's full attention instead of competing with tab-switching between five tools.

Incidents that page the actual on-call, not a static list

A contact list saved six months ago pages whoever used to be on call, not whoever's actually holding the pager tonight.

Reading the live rotation and opening the war-room channel from the same trigger means the page and the place to coordinate show up together, not five minutes apart.

Step 1
Live rotation, not a snapshot
Pages whoever's on call right now.
Step 2
War room opens with the page
Same trigger, same moment — no five-minute gap.
Step 3
Every page logged
Timestamped for the postmortem, automatically.

SLA breaches logged before the second angry email

By the time a support lead notices a ticket in the spreadsheet, the customer has usually already followed up twice.

Loop open tickets against their SLA policy, exclude paused time, and log every check — the row exists before the manager has to ask.

Step 1
Elapsed time, not guesswork
Calculated against the actual policy threshold per tier.
Step 2
Paused time excluded
A customer's own delay doesn't count against the agent.
Step 3
Every check logged
The weekly review reads a row, not twelve open tickets.

Connect the tools operations already runs on

Nobody gets to pick one tool for handoffs, one for incidents, and one for runbooks in a growing org — the ticketing system, the PM boards, and the chat tool are already fixed, and usually different per team.

These are the integrations most Operations workflows actually use. An HTTP step reaches anything else with an API, including internal tools.

Project Management

Support

Communication

Developer Tools

See the full catalog — every app we support, plus an HTTP step for anything else.Explore all WEXTL integrations

68+ apps for Operations

Integrate Operations workflows with the tools your team already uses.

Browse Support apps

Operations, by hand vs. with WEXTL

Task	By hand	With WEXTL
Cross-team handoffs	Links in chat, hope someone picks it up	Supported
Incident response	Different playbook every time	Same severity rules and notifications
SLA tracking	Friday spreadsheet review	Supported
Runbooks	PDF on the wiki	Executable steps with logs

Frequently asked questions

Severity is checked against saved criteria for the affected service — a customer-facing outage vs. a degraded internal tool aren't the same trigger. SEV1 pages the on-call rotation and opens a dedicated war-room channel; SEV3 opens a standard ticket with no page. The thresholds are set per service, not one blanket rule for everything that alerts.

Start automatingDrop this workflow into your WEXTL workspace and connect your own accounts.

Browse solutions & templatesExplore team solutions and ready-made workflow templates.

Run the business without running in circles

Operations automation, at a glance

Operations patterns on one canvas

Cross-team handoffs with context

What operations actually fights all day

The first 20 minutes of an incident

SLA clocks nobody's watching

Runbooks that drift from reality

Example: automate incident response

1. Alert fires or is declared

2. Classify severity

3. Page the right on-call and open the war room

4. Draft the status update

5. Hold for approval

6. Create follow-up tasks, escalate, and log

Example: automate SLA breach escalation

Who operations workflow automation is for

IT/Service Operations Managers

On-call engineers and SRE leads

Support Operations leads

Business/RevOps teams

Ops teams maintaining runbooks

Teams running a shared on-call rotation

Incidents that page the actual on-call, not a static list

Live rotation, not a snapshot

War room opens with the page

Every page logged

SLA breaches logged before the second angry email

Elapsed time, not guesswork

Paused time excluded

Every check logged