4
min read
Posted on:
Nov 3, 2026
Last updated:
Nov 3, 2026

What is IT workflow automation for businesses?

What is business workflow automation in IT? See where rules-based automation tools fall short and how AI agents resolve requests in Slack and Teams.

Aron Solberg
Co-founder & CEO @ Risotto
Abstract illustration of an office workspace with a desk, chair, and plants, representing IT workflow automation for businesses.

'We don't want to go build a bunch of traditional recipe-driven automation that's going to break.'

That's how one IT lead at a digital health company described the problem with rules-based workflow automation. You can automate routine tasks with tools like Okta Workflows or Zapier, but someone still has to build every workflow, troubleshoot failures, and keep everything running. And the requests a workflow can't handle still land on IT.

Building your own workflows with AI has the same catch: Someone still has to maintain them.

AI agents offer a different approach. They understand requests written in natural language, follow your team's instructions, and complete work in connected systems, with approvals and security controls in place.

Below, we'll explain how AI agents change business workflow automation for IT, where traditional approaches fall short, and how to start automating your own workflows.

TL;DR

  • Rules-based workflows need requests in a set format, and many just turn the request into a ticket without doing the work, so it still lands on IT.
  • An AI agent understands requests in the employee's own words, gets sign-off from the approver in Slack or Teams, then completes the task using instructions your team writes in plain English.
  • AI agents also handle work nobody asks for, like offboarding that starts when an account is deactivated, or checks that run on a set schedule.
  • The agent can only act within the access rules and approvals your team sets, and every action is logged.
  • Start with one frequent request, make sure the time it saves outweighs the setup, and track how many requests it resolves without IT; Risotto auto-solves up to 70% of Tier-1 requests.

What is business workflow automation?

Whichever approach you use, the work being automated is much the same: routine IT tasks that follow a repeatable set of steps. 

A workflow can start when someone asks for something, when something changes in another system, or on a set schedule. 

Common business process automation workflows in IT include:

  • Access requests and software provisioning. Handling each access request from approval through to granting access, and removing access when it's no longer needed.
  • Password resets and account lockouts. Verifying the employee's identity, then resetting their password or unlocking their account.
  • Onboarding and offboarding. Creating accounts and app access for new hires, and removing them when someone leaves.
  • Escalated ticket research. Pulling together logs and account details on a ticket before it reaches an engineer.
  • Scheduled checks. Running routine maintenance at set times, like flagging accounts that should have been removed.

How traditional workflow automation works, and where it breaks

Rules-based automation runs on 'if this, then that' logic. When something specific happens, like a form being submitted, the tool takes a set action, like sending the request to an approver.

This works well when every request comes in the same way. Unfortunately, many IT requests don't. Here's where rules-based workflows tend to break:

  • Requests have to match the expected format. The workflow only runs when the employee uses the right form or the right words. If not, someone in IT has to read the request and handle it.
  • Exceptions need manual handling. A workflow only covers the cases it was built for. When a request falls outside them, such as a higher permission level than usual or an app with no licenses left, the workflow has no next step, so the request goes back to IT.
  • Knowledge sits with one person. Often only the person who built a workflow knows how it works. When they leave, that knowledge leaves with them. One AI company we spoke to found an outdated automation set up by a former security engineer, which nobody on the current team knew existed. Without an owner or documentation, even a small change means first working out how the workflow was built.
  • Failures go unnoticed. A workflow depends on the systems it connects to staying the same. When one of those systems changes, the workflow can stop working, and the team isn't notified.
  • Someone has to keep checking. Because broken workflows don't get flagged, teams have to check their automations manually. A fintech startup admin we spoke to checks a homegrown sync 'once a month, twice a month just to make sure that the data is actually syncing.' That's the kind of work the automation was supposed to remove.
  • Plan limits cap what you can automate. Some tools charge per workflow or limit how many you can run. On a more basic plan, IT has to choose which few requests to automate and leave the rest manual. One VP of IT we spoke to, on a plan capped at five flows, said going beyond five 'would be a dream come true.'

These problems add up. Every new workflow brings more rules to build, test, and fix, and more places for something to break.

Another issue is that many rules-based workflows only handle the admin around a request. They create the ticket, route it to the right team, or send a notification. They don't resolve the request end to end, so someone in IT still has to do the work itself.

For example, an education nonprofit we spoke to uses Zapier to send Slack requests into Freshservice. From there, in their words, 'it's a manual process.' Their automation also creates a checklist for each new hire or departure, sometimes up to 40 tasks long, and IT completes every one manually.

How AI agents change IT workflow automation

AI agents solve many of these problems by changing two things: how the work starts and how far it goes. 

A rules-based workflow waits for a specific trigger and follows fixed steps. An AI agent, on the other hand, reads the employee's request, works out what they need, and follows the runbook your team wrote for that kind of request. If it can't finish, it passes the request to IT with everything it has gathered so far.

The table below compares the two approaches:

Rules-based automation AI agent workflow automation
Input it needs A specific form, answers, or keywords A request in the employee's own words, via chat or email
How the workflow is picked Matches a set trigger, like a submitted form Works out what the request is about and picks the matching runbook
When the request is unclear Goes to IT's queue Asks a follow-up question, or passes the request to IT with context
Who builds it Usually a technical person familiar with the automation tool The team that owns the process writes the runbooks, and admins set up the tools
Maintenance Rules need rebuilding and retesting as requirements change The workflow owner edits the runbook when the process changes, and admins manage the app connections
Scope Often one step in one system, like creating or routing a ticket The whole request, across connected systems, within the permissions you set

AI agents still use deterministic logic for steps that require precise, predictable behavior. The difference is that they can combine those steps with natural-language understanding.

Let's look at how that works using a software access request as an example.

It understands requests the way people write them

Employees rarely ask for the same thing in the same way. One might ask, 'Can I get Figma?' Another might write, 'I need Figma access to review next quarter's roadmap.' 

A rules-based workflow needs both phrases added as options, so it can pick the right request type or fill in the right form. An AI agent recognizes they're asking for the same thing.

It also handles more than one request at a time, or a request made for someone else. Maya, a designer, writes in Slack: 'Can you give Kai and me access to Figma? We need to review the roadmap.' The agent understands that two people need access and handles both.

Employees ask for help the way they'd ask a colleague, which is the idea behind conversational ticketing.

It collects missing details and approvals in chat

Approvals are often where a simple request stalls. When approval requests arrive by email or sit in a ticket queue, approvers miss them. 

At one payments company we spoke to, approval emails from Jira often went unanswered, while a message in the team's chat tool, Slack, was 'very hard to ignore.'

An AI agent sends the approval request to where the approver already works, like Slack or Microsoft Teams. 

Back to Maya's request; her company has two Figma seat types, standard and paid, and each has a different approver. 

The agent checks the access rules to see which approval applies. Maya already gave a reason, but the rules also ask for a time limit, so the agent asks how long they need access. The approver gets a message in chat and approves it there, and Maya gets a status update in her original thread.

IT keeps its approval process, and employees spend less time waiting for an answer. As one admin at a compliance software company put it: 'I don't want to circumvent the process. I just want people to approve it.' 

In Risotto, the request, the approval, and the action all sit on one ticket, because the service desk and the automation engine are one system.

It follows your team's instructions and completes the task

Once it has the details and the approval, the agent follows your team's runbook to complete the task. 

Runbooks are written in everyday language, the same way you'd explain a process to a new hire: when this kind of request comes in, take these steps. For steps where there's no room for error, like changing someone's access, the runbook can tell the agent exactly which tool to use, so it doesn't pick one itself.

In Risotto, for example, department supervisors can write their own runbooks, while admins set up the tools those runbooks use. The team that knows the process writes down how it should work, and the agent carries it out.

For Maya and Kai, the runbook tells the agent to grant Figma access through the connected app or identity system, then confirm in Slack.

When the agent can't finish a task, it hands the request to IT with everything it has gathered, so nobody has to start over. If no paid Figma seats were left, for example, IT would get the request with the approval requirements already on the ticket.

In Risotto, the Assistant also picks up from there. It investigates the escalated ticket using read-only actions and proposes a plan for IT to approve.

It handles work that doesn't start with a request

Requests like Maya's start with someone asking. Other IT work begins when something changes in another system, or runs on a set schedule. An AI agent handles that work too, and carries it across several systems at once.

Offboarding is a good example. Done manually, it means logging in to each system in turn, from the identity provider to GitHub to 1Password, and removing access one by one.

With an AI agent, the change in another system starts the process. When an account is deactivated in the identity provider, or the HR system sends a webhook, the agent removes access across connected systems, updates records, and notifies the right teams. Steps that need sign-off still wait for approval.

In Risotto, requests that come in through chat run through no-code runbooks. Work that starts on its own, like offboarding, runs as an automation triggered by an event or a schedule.

Ready to write a workflow in plain English and watch Risotto run it in Slack? Book a demo.

How AI workflows stay secure

If you're wary of giving an AI agent access to your identity systems and apps, you're not the only one. One IT leader we spoke to described it as handing over 'large parts of the keys to the kingdom.'

Understanding a request doesn't give the AI agent permission to act on it. Your IT admins decide which systems and tools the agent can use, and the access rules and approval policies your team sets decide which actions it can take. The agent can't override either. 

In practice, that control comes from a few safeguards:

  • Approval for sensitive actions. Sensitive actions wait for a person to sign off. For example, the agent can't grant admin access until the system's owner approves it.
  • Eligibility rules. Employees can only request what they're eligible for. For example, only engineers might be able to request AWS access.
  • Time-limited access. Access can be granted for a set period, like 24 hours, and is removed automatically when it ends.
  • A full audit trail. Every request and automation is logged with who asked, who approved, what was done, and when. Changes to the setup are logged too.
  • Failure notifications. If a step in an automation fails, the automation stops and goes to IT with the details, so nothing breaks without anyone knowing.
  • Human review for sensitive HR work. Teams can automate most of an HR process, like a pay change, and still have a person check it before anything goes out.
  • Independent security audits. An outside auditor has reviewed how the vendor protects your data, against a recognized standard such as SOC 2 or ISO 27001.

On the Risotto platform, access rules set who's eligible to request each app, and permissions are scoped by department and role. 

Automation run history and ticket activity record every action, a separate audit log tracks changes to the setup, and a failed automation run can be re-run from the start. Risotto is also SOC 2 compliant.

How to automate an IT workflow

With these security safeguards in mind, our advice is to start small. Your first automation should get one common request auto-solved, while exceptions and approvals still reach the right people. Here's how to get there:

  1. Pick the right request. Look for something your team handles often and in roughly the same way each time. Access requests, password and 2FA lockouts, and account creation are common first choices. Write down how it's handled today, including when it should go to a person.
  2. Check that it's worth automating. Multiply how often the request comes in by how long it takes to handle manually, then compare that with the time it will take to set up. As one IT lead at an identity company put it: 'If it takes 10 hours to build something that saves 10 hours, it's not really worth your time.'
  3. Connect the systems it needs. That usually means your identity provider, HR system, device management, and existing ticket system. In Risotto, for example, tickets sync two ways with Jira Service Management, ServiceNow, Freshservice, and Zendesk.
  4. Build the workflow. Start from a template or describe the steps in plain English. Set what starts it (a request, a change in another system, or a schedule) and what it should do. In Risotto, for example, you can start from a pre-built runbook template or have the Assistant draft one from a description. Admins set up automations that run on events or schedules.
  5. Set approvals and test the exceptions. Decide which steps need sign-off and who can request the workflow. Before anyone else uses it, test what happens when details are missing, an approval is rejected, or a step fails.
  6. Launch it. Turn the automation on. From then on, whenever an employee makes that request in Slack, Teams, or email, the automation handles it.
  7. Track the auto-solve rate. Count only the requests IT didn't touch at all. As one IT manager put it: 'if a human touches it, it’s not automated.' In Risotto, this is the 'Solved automatically' figure on the dashboard. The requests that still need IT show you what to automate next.

Where to start with IT workflow automation

Rules-based automation works well for requests that always arrive the same way. Most IT requests don't, which is why so many still land on IT. AI agents close that gap. They handle requests the way employees write them and see the work through, within the approvals and permissions your team sets.

Risotto is an AI ITSM that puts the service desk and the automation engine in one system, so the request, the approval, the action, and the record all live in one ticket. 

It works in Slack and Teams, alongside the ticket system you already run, and auto-solves up to 70% of Tier-1 requests. Your team can automate IT workflows by writing the steps in plain English, or have the Assistant draft them.

Liked the article? Share on:

Get your first IT workflows running in days, on the ITSM you already use