How to build and govern IT workflow automation with your own team

TL;DR

• In our view, most IT teams can build their own IT workflow automation, starting with self-service. What’s missing is a method.
• Start low on our seven-rung blast radius ladder, write down the only actions the automation may take, and try to break it before launch.
• Get help where no connector exists, or where a change touches identity.

If it’s the 40th “how do I get a second monitor?” ticket of the month and a consultant’s six-month quote sits in your inbox, start here. Building IT workflow automation is the easy part, and we say that as the team behind Computer, by DevRev – our AI teammate – and its Agent Studio builder. The hard part is deciding what an automation is forbidden to do. Teams that skip that step hire the consultant anyway, to clean up after the bot.

How much can your own team build first?

Your own team can build the low-risk first automations, whichever platform you build on. The table shows where that stops.

If you bring in builders, plan the handover first. Your team has to be able to explain the result to an auditor and change it alone.

Before you build: four things to have in place

• A clean knowledge source: one current, approved article per policy. If two disagree, the automation picks one for you.
• A ticket taxonomy: the categories a ticket needs to land in the right queue.
• A named owner: a person, because you can’t ask a team alias why something happened.
• A decision on who approves what: made now, by people.

An eight-step method for building IT workflow automation

The method runs in eight steps, from picking a low-risk first workflow to giving it an owner, around one worked example: an employee asks, “Can I get a second monitor?” Each step shows how it’s done in Computer, and the steps themselves work on any platform. In Computer, the internal agents employees talk to are still marked “coming soon,” so treat each step’s Computer settings as what to plan for until those agents reach your workspace.

This is desk research: we built each step from our help center and published security guidance as of October 2026, not from a test build, so confirm each Computer setting against your own plan and workspace. The Reddit quote in step 5 is one practitioner’s experience, linked and dated. It shows how people describe the problem, not how common a view is.

Step 1: Pick a first workflow with a small blast radius

Blast radius is the damage an automation can do when it goes wrong at full speed: what it can change, and who it can affect. Start with a request where the worst outcome is a wrong answer. Rank your candidates by what they can break, then take the lowest rung that gets asked every week.

The worked example lives on rungs one to three, where nothing is hard to undo. It touches rung four only when a purchase needs a manager. The password reset everyone wants to automate first sits on rung five, because it changes who can get into an account.

Skipping the ladder has a price. Gartner expects 40% of enterprises to demote or decommission autonomous AI agents by 2027 “due to governance gaps identified only after production incidents occur.”

Amar Gautam, Head of DevRev Labs, argues in his essay on employee self-service that trust gets earned from the bottom up:

“Enterprises move slowly here, mostly for good reasons, and trust in systems that act will be earned one category at a time, starting with the boring ones.” – Amar Gautam, Head of DevRev Labs

So pick a first automation so dull that nobody notices it, and so useful that everybody would miss it. In Computer, rung one runs on knowledge articles. Each one has a required owner, and a tag puts it in AI-powered search.

Step 2: Define what starts it, and what doesn’t

The trigger is the event that wakes the automation up. Keep it narrow, and write down what it must ignore.

Name the channel, the request type, and a few real phrasings from old tickets. Then list what’s out of scope: payroll, security incidents, and another person’s access. A trigger that catches everything becomes the front door for requests you didn’t plan for.

In our example, the automation starts when an employee asks an IT policy question in the help channel. It ignores thread replies and messages from service desk staff. Don’t match on keywords alone, since “monitor” also appears in “my monitor is on fire.”

In Computer, every workflow has one trigger, and our docs recommend filter conditions on all of them. A topic guardrail keeps the agent to the topics you define.

Check one thing before you start: this example needs an internal agent, the kind employees talk to. The same help article still marks internal agents “coming soon,” so check with us whether they’re available in your workspace before you build.

Step 3: List the context it needs, and where each piece comes from

Context is what the automation must know about the person asking. Each item needs one named system of record.

The monitor question needs these facts:

• Who is the employee?
• What is their department, location, and current device?
• What are they entitled to?

Write the source beside each one. If your monitor policy gives contractors a different answer, an automation that doesn’t know who’s asking gives them the employee one.

Two sources for one fact cause trouble. If human resources (HR) and the identity provider disagree, pick the one a person maintains. Treat an empty field as a test case, too, and decide now whether the automation asks the employee, opens a ticket, or stops.

In Computer, most of that context arrives through AirSync connectors, which import data. Our Okta connector imports users, groups, applications, and devices from Okta, which secures identity for employees and customers. The Azure Entra ID AirSync connector brings in users, groups, and memberships from Microsoft Entra ID, Microsoft’s cloud-based identity and access management service.

The Workday connector adds location from Workday, which makes software for HR, finance, and IT. Our docs describe all three as one-way imports, so they supply context and change nothing in the source system.

Step 4: Write down what it’s allowed to touch

An authorized action is one thing the automation may do in one named system. List every authorized action, then declare everything else forbidden. For a first automation, the list should fit on a sticky note. Fill in the build sheet before you open a builder, because security will ask for it.

Here’s the blank version, to paste into a doc:

• Trigger:
• Not a trigger:
• Required context, and the source of each item:
• Authorized actions:
• Forbidden actions:
• Approval gate, approver, and backup:
• Exception paths:
• Owner:
• Review date:

The Open Worldwide Application Security Project (OWASP), a nonprofit that works to improve software security, publishes a Top 10 risk list for large language model (LLM) applications. It names a risk called excessive agency: a system with more functions, permissions, or autonomy than its job needs. OWASP’s first fix is to limit what an agent can call to “only the minimum necessary.” So refuse any broad permission granted “for later,” because later is when nobody remembers why it’s there.

In Computer, three layers stay apart. Connectors import data, the channel you deploy the agent to is where people ask, and skills let the agent act. Our Agent Studio docs say it directly: “Without skills, an agent can only answer questions.”

A skill can be a built-in operation or a workflow. The workflow action library lists actions that create a ticket, update it, and add a comment. The Agent Studio task reference lets you choose which knowledge sources the agent can use.

Want to try the worked example? Follow our guide to building your first agent.

Step 5: Put a person in front of anything with consequences

Approval belongs where a mistake is expensive or hard to undo. Everywhere else, it’s a delay with a signature on it.

Ask two questions of each authorized action: what does a mistake cost, and can we undo it? A policy answer needs no approval, but a purchase needs a manager. Name the approver and a backup, and decide what happens if neither answers.

An approval step nobody ever rejects is a rubber stamp. In an r/sysadmin thread on automating approvals without losing accountability, one admin tested for it by asking the owners of their team’s workflows:

“I eventually had to start asking ‘when is the last time you rejected XYZ?’” (r/sysadmin, October 2025).

Once the answers showed those approvals were a formality, the team replaced them with a weekly report. Expect security to ask the same kind of question: who approved this, what did they see, and where is the record?

Megha Rawat, from our Global Support team, states the principle behind an approval gate in her post on rethinking customer support:

“Every autonomous system requires clearly defined limits. It must know where it can act independently and where it must defer to human judgment.” – Megha Rawat, Global Support at DevRev

Every skill in Computer’s Agent Studio carries a “Needs Approval” setting. It starts switched off, so turn it on for each skill that changes something, and the agent asks the person in the conversation to confirm first.

For a manager’s sign-off, the Ticket approval workflow, a snap-in from our Marketplace, lets the service desk ask for approval inside the ticket.

Step 6: Plan the exceptions before they happen

Decide in advance what the automation does when it shouldn’t answer, and make every one of those paths end at a person.

• No matching policy, or a weak match: it says so and offers a ticket instead of guessing.
• Missing context: it asks once, then hands off.
• Two policies that disagree: it quotes neither and flags both to their owners.
• An upset employee, or “let me talk to a person”: it hands off at once, with the transcript.

Never leave a dead end. “I can’t help with that,” with no ticket and no person, teaches employees to skip the automation and message your team.

Hold off on anything where the policy lives in one person’s head. Gautam’s essay calls the deciding factor “policy clarity.”

In Computer, you write escalation procedures into the agent’s instructions. The agent can create a ticket or notify your team once you set that up as a skill.

Step 7: Test it by trying to break it

Test the cases you hope never happen. If the automation only passes polite questions with clear answers, you’ve tested the easy half.

Test with a contractor’s account, not only your own. You have admin rights, and the contractor doesn’t.

Prompt injection deserves the most attention. OWASP ranks prompt injection first among risks for LLM applications and says it’s unclear whether a foolproof fix exists. That’s the argument for step 4: an automation with three permitted actions gives an injection little to work with.

The US National Institute of Standards and Technology (NIST) released its AI Risk Management Framework 1.0 in January 2023. NIST’s framework page says it’s being revised, and 1.0 is still the current version. The framework says AI systems “should be tested before their deployment and regularly while in operation.”

Our “Inside the studio” video shows our product team building a customer-support agent live. The testing method is the same for an IT agent, so jump to 17:26 for testing and monitoring.

In Agent Studio, a new agent starts in “Draft” and doesn’t respond to real messages, according to our task reference. The Agent Studio reference adds bulk testing with a comma-separated values (CSV) file that has three columns:

• Input.
• Expected Output.
• Remarks.

Step 8: Give it an owner and a review date

An automation without an owner is a future incident. Name one person, tell them what to watch, and put a review in the calendar.

For the first month, the owner reads a sample of conversations every week. They count four things:

• Questions.
• Tickets.
• Handoffs.
• Answers flagged as wrong.

Review the build sheet every 90 days. Pick the owner by role, not by who built it, because builders change teams.

The same NIST framework asks for documented roles and responsibilities. It also asks for a way to “supersede, disengage, or deactivate” a system whose results drift from its intended use.

In Computer’s Agent Studio, the “Observe” tab shows an analytics dashboard and session traces once you switch analytics on for each agent. Only members of the Agents and Automation Admins group can deploy workflows and view their runs.

Bring your step 7 “break-it tests” to a demo. We’ll run them as a bulk-test CSV on an agent still in “Draft” in Computer, then open the “Observe” tab to show the session traces its owner will check. Book a demo →

Take your own before-and-after numbers

Take the baseline before you launch, while your queue still shows how things run without the automation. Pull a month of the tickets it will cover, and count the policy questions, the handoffs, and how long each ticket took to close. At the 90-day review, set the owner’s counts from step 8, and the same close times, beside that baseline.

Climbing the ladder: what to confirm before the next rung

Before you build anything that writes to an identity or device system, confirm three things.

1. The action is supported: our service desk page describes templates for password resets and software access. The step 3 connectors only import data, so the change runs through an action you attach to the agent: a Model Context Protocol (MCP) connector, an HTTP step in a workflow, or a custom snap-in.
2. Security has reviewed it: in his essay, Gautam writes that in every deployment he’s been part of, “the actual critical path was the security review, not the technology.”
3. Every action leaves a record: who asked, who approved, and what changed. Our audit logs capture API calls, with who made them and when.

Where no supported action or connector exists, building one is a developer’s job. Our implementation partner program can help.

So the consultant’s quote earns its place only where no supported action exists. Everything below that line is your team’s to build, as long as each automation has a written list of what it may touch, a named owner, and any security or compliance sign-off it needs.

Show us your build sheet in a demo, and ask the question your security team will ask first: what can it touch? Book a demo →