Operations Agent Playbook

Internal operations work is full of repetitive, rule-based tasks: routing a purchase request, provisioning access for a new employee, creating Jira tickets from incident alerts. These workflows have clear inputs, predictable decision trees, and defined outcomes — the kind of work where an agent handles the intake and routing and a human reviews only the exceptions. This playbook covers three concrete example workflows — procurement intake, employee onboarding task creation, and incident routing — using ProvenanceOne step kinds that map directly to how your operations processes already work. Each example includes explicit approval thresholds: below the threshold, the agent acts; above it, a human decides.

---

What this agent does

Operations agents automate the intake, classification, routing, and task creation layer of internal workflows. They do not replace your ITSM systems, project management tools, or approval authorities. They connect those systems together, apply your routing logic, and handle the work that currently requires a human to read a form, decide where it goes, and create the downstream task manually.

This playbook documents three example workflows. Each uses a different trigger type and a different action target, but all share the same structural pattern: trigger → data → logic → approval (when required) → action → notify → storage.

Example A — Procurement intake An employee submits a purchase request via a form. The agent parses the submission, checks it against purchasing policy, and either auto-approves below the threshold or routes to finance for approval above it. The outcome is a PO in ServiceNow and a Slack notification to the requester.

Example B — Employee onboarding task creation An HR system fires a webhook when a new employee record is created. The agent reads the employee's role and department, creates the appropriate Jira task lists for IT, HR, and the hiring manager, and schedules a reminder for incomplete tasks on day 3.

Example C — Incident routing A PagerDuty alert fires a webhook. The agent classifies the severity and affected service, routes P1 incidents to an approval step and immediate Slack alert, creates Jira tickets for P2 incidents, and auto-resolves P3 incidents with a log entry.

---

Best-fit use cases

This playbook is well-suited when:

• Your team handles high volumes of intake requests (purchase requests, access requests, IT tickets) that follow a defined decision tree more than 80% of the time
• Routing errors are common — requests go to the wrong team, miss required fields, or get stuck in email chains because the decision logic lives in someone's head rather than in a system
• You have existing ITSM or project management tools (Jira, ServiceNow) that you want to feed automatically rather than having employees create tickets manually
• Your approval thresholds are clearly defined and documented — operations automation requires explicit rules, not implied ones

---

When not to use this agent

Do not deploy this agent when:

• Your intake processes are genuinely unstructured and require judgment calls that do not map to a decision tree — agent steps can classify ambiguous inputs, but if your routing logic is "it depends on context that's hard to define," you need to document that logic before automating it
• Approval thresholds are unclear, contested, or change frequently — build the policy first, then encode it in the workflow
• You are automating actions in production systems (ServiceNow, Jira) without having tested the action steps in a staging environment first — a misconfigured action step that creates thousands of malformed tickets is difficult to undo
• Your operations team has not reviewed and signed off on the routing logic — agents encode decisions, and those decisions should come from the people who own the process, not from a workflow builder's interpretation

---

Required connections and data sources

Connection	Purpose	Auth method
Slack	Notify requestors, ops team, and approval assignees	OAuth 2.0
Jira	Create and update tasks for onboarding and incident routing	API Key
ServiceNow	Create purchase orders and IT service records	Service Account
PagerDuty (optional)	Receive incident alert webhooks for Example C	API Key

Configure connections in Workspace → Connections before building any of the three workflows. The ServiceNow Service Account requires write access to the relevant tables (Purchase Orders, Incidents). The Jira API Key requires project-level permissions to create and update issues in the relevant boards. See /docs/connections/index.

For webhook triggers (Examples A and C), configure the source system to send the event payload to your ProvenanceOne workspace trigger URL. For Example B, configure the HR system webhook to fire on the employee.created event.

---

Recommended agent instructions

An agent step is appropriate for classification tasks — determining severity, validating policy compliance, or extracting structured data from unstructured text. Use agent steps sparingly in operations workflows: most routing logic belongs in logic steps, not agent steps.

Incident classification agent (category: reasoning, trust: medium, used in Example C):

You classify IT incidents for a support operations team.

Given an alert payload including alert name, affected service, error message, and environment, return a JSON object with:
- severity: one of [P1, P2, P3]
- affected_service: the primary service identified from the alert
- classification_rationale: one sentence explaining the severity assignment
- confidence: a number between 0 and 1

Use the following severity criteria:
- P1: production outage or data loss affecting multiple users; customer-facing impact confirmed or likely
- P2: degraded performance or partial outage; investigation required; no confirmed data loss
- P3: non-urgent, informational, or pre-emptive alert; no user impact

If the alert does not contain enough information to classify with confidence above 0.7, return P2 and note the missing information in the rationale.

For procurement policy validation (Example A), a skill step running a policy-check function is more appropriate than an agent step — policy checking is a deterministic lookup against defined thresholds, not a reasoning task. Reserve agent steps for genuinely ambiguous classification problems.

---

Required skills and tools

Skill	Category	Purpose
Policy checker	transform	Validates a procurement request against defined thresholds (amount, category, vendor); returns approval_required boolean and reason
ServiceNow PO creator	integration	Creates a purchase order record in ServiceNow with the provided fields
Jira task creator	integration	Creates one or more Jira issues in a specified project and sprint
Employee record reader	data	Reads employee record from HR system webhook payload or data warehouse
PagerDuty alert reader	data	Parses the PagerDuty alert webhook payload into a structured format

Attach skills to agent steps only when the agent needs to call the skill during its reasoning. For action steps, skills are invoked directly — not through an agent. The Jira task creator and ServiceNow PO creator should be used in action steps, not attached to agent tool lists. See /docs/skills/index.

---

Recommended workflow design

Example A — Procurement intake

1. trigger step — type webhook. Source: your internal purchase request form (e.g. Typeform, an internal portal, or a Slack /request command). The payload must include: requester email, item description, amount, vendor name, and cost centre.

2. data step — parse the request form payload. Extract and validate required fields. If any required field is missing, route to a notify step that asks the requester to resubmit with the missing information and ends the run.

3. skill step — policy check — policy checker skill. Input: amount, category, vendor. Output: approval_required (boolean), threshold_applied, reason.

4. logic step — routing — branch on approval_required:

   • If false (under threshold): route to action step → create PO in ServiceNow → notify requester
   • If true (over threshold): route to approval step

5. approval step — for over-threshold requests. Configuration: risk: medium, slaMinutes: 1440 (24 hours), assignees: [email protected]. Evidence: amount, vendor, cost centre, requester name.

6. action step — ServiceNow PO creator skill. Creates the PO record with requester, vendor, amount, cost centre, and approved-by fields populated.

7. notify step — Slack message to requester's Slack ID confirming PO number and expected processing time. Notify the ops channel for monitoring.

8. storage step — write the full request, routing decision, approval outcome, and PO number to the audit datastore.

Example B — Employee onboarding

1. trigger step — type webhook. Source: HR system employee.created event. Payload includes: employee name, email, role, department, start date, manager email.

2. data step — employee record reader skill. Parses the webhook payload into structured fields. Validates that all required fields are present.

3. logic step — department branch — branch on department value to determine which Jira project and task template to use. Each department (Engineering, Sales, Finance, Operations) has a defined task list template stored in your configuration.

4. action step — IT tasks — Jira task creator skill. Creates tasks for: laptop provisioning, software access, email setup. Assignee: IT team lead. Due date: employee start date minus 2 days.

5. action step — HR tasks — Jira task creator skill. Creates tasks for: benefits enrolment, policy acknowledgement, welcome call scheduling. Assignee: HR business partner for the department. Due date: employee start date.

6. action step — manager tasks — Jira task creator skill. Creates tasks for: 1-on-1 scheduling, 30-day plan review, team introductions. Assignee: manager email from payload. Due date: employee start date.

7. notify step — Slack message to manager with links to their Jira tasks. Slack message to HR confirming task list was created.

8. storage step — write the onboarding record (employee email, start date, task IDs, creation timestamp) to the datastore.

9. Scheduled sub-workflow — configure a separate workflow triggered on schedule at day 3 post-start-date. This workflow reads the onboarding record from storage, checks Jira task statuses via the Jira API, and notifies the manager and HR if any task is still To Do or In Progress.

Example C — Incident routing

1. trigger step — type webhook. Source: PagerDuty alert. Payload includes: alert name, service, severity hint, environment, error message.

2. data step — PagerDuty alert reader skill. Parses the webhook payload into structured fields.

3. agent step — classification — incident classification agent. Input: alert payload. Output: severity, affected_service, classification_rationale, confidence.

4. logic step — severity routing — branch on severity:

   • P1: route to approval step AND simultaneously route to notify step (parallel branches — alert on-call team immediately; approval gate holds further action)
   • P2: route to Jira action step (create incident ticket for investigation)
   • P3: route to storage step (log and resolve)
   • Unclassified (confidence < 0.7): route to approval step with risk: medium

5. approval step (P1) — risk: high, slaMinutes: 30, assignees: on-call engineer + engineering manager. Evidence: severity, affected service, classification rationale, confidence.

6. notify step (P1) — immediate Slack alert to #incidents channel and on-call engineer DM. Fires in parallel with the approval step so the on-call is aware before they receive the approval request.

7. action step (P2) — Jira task creator skill. Creates incident ticket in the Engineering project with affected service, alert details, and classification rationale.

8. storage step — write routing decision, classification output, and outcome to the audit datastore for all severity levels.

---

Human approval rules

Operations workflows benefit from explicit, documented approval thresholds. Define these before building the workflow.

Approval required:

Action	Risk level	SLA
Procurement above $500	medium	24 hours
Account permission changes	high	4 hours
Vendor contract creation	high	48 hours
Service configuration changes in production	high	2 hours
Unclassified incident (confidence below 0.7)	medium	30 minutes
P1 incident response actions	high	30 minutes

No approval required:

• Read-only data retrieval in any data step
• notify steps — Slack messages and email notifications
• Task creation in Jira or other project management tools for onboarding or standard requests
• Onboarding task lists (no system access changes)
• Procurement requests below $500 that pass policy check

Encode these thresholds in logic steps with explicit branch conditions. Do not rely on the agent to determine whether approval is required — that is a logic step responsibility. Agents classify and reason; logic steps enforce policy. See /docs/approvals/index for approval step configuration.

---

Security and permission model

Role	Permissions
admin	Configure Slack, Jira, ServiceNow, and PagerDuty connections; publish workflows; manage approval assignees
editor	Create and edit agents, skills, and workflow steps; view run history and audit log
viewer	View workflow runs and approval status; cannot approve, edit, or trigger runs
the identity service approvers group	Grant or reject approval requests

ServiceNow and Jira credentials are stored in the secrets vault and are never returned in API responses. connection.accessed and secret.accessed audit events are emitted on each use.

The Jira task creator and ServiceNow PO creator skills run in a serverless function sandbox. They have no network access beyond the configured target endpoint. They cannot read or write to any other system.

For onboarding workflows, the employee record from the HR webhook may contain PII. Do not store full employee records in agent memory or in the workflow run log beyond what is required for debugging. Configure data retention for runs containing PII in Workspace → Settings → Data Retention.

Audit events emitted by these workflows: run.started, run.completed, run.failed, approval.granted, approval.rejected, approval.sla_breach, connection.accessed, secret.accessed.

---

Evaluation checklist

Before deploying any of the three example workflows to production, validate the following:

• Agent routes requests to the correct destination in at least 95% of test cases — test with real request payloads from your intake backlog
• Approval thresholds match your policy exactly — test with borderline amounts (e.g. $499 and $501 for a $500 threshold) and verify routing is correct in both cases
• Slack notifications arrive in the correct channels with the correct content — test with real Slack workspace accounts, not test accounts
• Jira tasks contain all required fields with no empty or placeholder values — check each field the Jira task creator populates against your project's required field list
• ServiceNow PO records are created with valid field values — verify against ServiceNow's field validation rules, especially mandatory fields and list values
• Audit datastore captures the full chain from trigger to outcome — verify by querying the datastore for a test run and checking that all steps are represented
• Agent handles missing or malformed input gracefully — test with partial form submissions (missing cost centre, missing requester email) and verify the workflow returns an appropriate error or routes to a notify step, not a silent failure
• P1 incident approval SLA is achievable — verify that the on-call assignees are reachable via both Slack and email and can approve from mobile

---

Rollout plan

Phase 1 — weeks 1–2: Shadow mode Run each workflow in parallel with the existing manual process. The agent classifies, routes, and would take action — but no actions are executed, no approvals are requested, and no messages are sent. Review the agent's routing decisions against what your team actually did. Identify misroutes and adjust logic step conditions.

Phase 2 — weeks 3–4: Low-risk automations only Enable notify steps and action steps for Jira task creation and Slack notifications. Keep all ServiceNow PO creation and approval requests manual — reviewed and confirmed by a human before the action step runs. This phase validates that notifications reach the right people and Jira tasks are created correctly.

Phase 3 — month 2: Full automation with approval gates Enable the full action step for ServiceNow PO creation and the approval step for over-threshold requests. Keep approval gates in place for all policy-threshold and exception cases. Review the audit log weekly for misroutes and SLA breaches. Adjust thresholds and assignees based on observed patterns.

---

Common failure modes

Logic step misroutes an edge case (purchase spanning two cost centres). The logic step has no branch for split-cost-centre requests, so it defaults to the standard low-risk path and auto-approves. Mitigation: add explicit handling for known edge cases in the logic step conditions. For any input pattern the logic step does not recognise, default to the approval branch rather than auto-acting. A missed approval is a recoverable problem; an incorrect auto-action may not be.

ServiceNow or Jira action step fails silently. The action step returns a success status but the PO or task was not actually created due to a field validation error in the downstream system. Mitigation: check the action step output payload in the run debugger — both systems return structured error responses that the action step captures. Add a notify step after every action step that alerts the ops monitoring channel when the action step output contains an error field, rather than relying on visual inspection of the run log.

Approval SLA breaches during holiday or out-of-office periods. The sole assignee is unavailable and the SLA breaches, leaving the request stuck in approval status. Mitigation: configure at least two assignees on every approval step — a primary and a backup. Set a Slack notification to fire at 80% of the SLA time to prompt action before breach. For 24-hour SLAs, 80% is ~19 hours — enough notice for the backup to respond before breach. See the SLA monitoring documentation in /docs/approvals/index.

---

ROI assumptions

The following inputs illustrate the cost-side case for operations automation. Replace every value with your actual data.

Input	Assumed value	Notes
Intake requests per month	150	Purchase requests, IT requests, onboarding events
Minutes per request — current manual handling	20	Intake, routing, task creation, notification
Minutes with agent — review and approve	5	Human reviews routing decision, confirms or corrects
Loaded hourly cost of ops staff	$55	Include benefits and overhead
Manual routing error rate	~15%	Requests sent to wrong team or missing required fields
Estimated error rate with agent	~5%	Needs post-deployment monitoring to confirm

At these inputs: 150 requests x 15 min saved x ($55/60) = $2,063/month in ops handling time recovered. Error rate reduction (fewer re-routes, fewer rework cycles) adds further leverage that is harder to quantify upfront — track pre/post SLA compliance as a proxy metric.

SLA compliance improvement is a meaningful secondary metric for operations workflows. Track it pre- and post-deployment by exporting audit log data for run.completed and approval.sla_breach events.

Use the ROI calculator for your specific inputs: /tools/ai-agent-roi-calculator?use_case=operations.

---

FAQ

---

Related pages

• Approvals — approval thresholds, SLA configuration, payload editing, SLA breach handling
• Agents — agent trust levels, system prompt guidance for classification tasks
• Skills — packaging and attaching serverless function skills for ITSM integrations
• Connections — setting up Jira, ServiceNow, Slack, and PagerDuty connections
• Workflow Runs — using the run debugger to diagnose routing failures and action step errors
• Audit — exporting audit events for compliance and process review
• Customer Support Agent Playbook — agent patterns for customer-facing workflows
• Sales Research Agent Playbook — agent patterns for the revenue team
• Approval Policy Template — pre-built approval policy structure for the procurement and incident routing gates
• Risk Assessment Checklist — score this workflow across 9 risk dimensions before deploying to production