Interested in a ServiceNow event built for developers? Registration for now[dev]26 is officially open!

Oluyinkaoginni
ServiceNow Employee

A Service Desk Team Lead who also owns the support process runs two questions at once. How do I get the team through today's work, and what needs to change so tomorrow's is better?

I believe the useful test for Agentic AI is the second question. Summarising a ticket helps with the first one, and what changes a week is work that starts as triage and ends as a root cause with a plan attached.

So at a recent Platform Academy session I built a demo scenario and followed one person through a single working day, watching four Agentic Workflows hand work to each other.

About this walkthrough: Mark, his team, and every record below are a demo scenario on a demo instance, built to show how these four Agentic Workflows connect. The workflow behaviour is real and the data is illustrative.

Morning: Clearing the Backlog (Help Optimize Team Productivity)

Meet Mark, who leads the Service Desk L1 team and owns how the support process performs.

His day starts with open Incidents waiting to be assigned, and he wants them distributed on capacity and experience rather than on whoever is free. Instead of reviewing every ticket by hand, he opens the Otto panel and asks for optimized assignment evaluations for the Service Desk L1 team.

The Work Allocator AI Agent weighs each person's workload against their typical capacity, their historical performance, and whether they have handled similar work before. It can use the fields that matter to this team, such as category and subcategory, when deciding what counts as similar. It evaluates the backlog in batches of 50 by default, with 100 the recommended ceiling, and looks back up to 60 days when weighing performance, and both of those are configurable in the Optimal Ticket Assignment Skill config.

The recommendations come back, Mark reviews them and nothing dispatched on its own.

Then came the part I care about most. Reading the recommendations, Mark noticed that a lot of these Incidents were about payment issues. He had seen that theme before, and he leaves the backlog review with a different question. Is this today's workload, or is something recurring creating demand for my team?

I suspect a number of you have been in Mark's shoes right there, spotting a theme in the queue that you have seen before and having no room that week to chase it.

Late Morning: Proving the Pattern in the Open (Analyze Task Trends)

Mark remembered a workflow called Analyze Task Trends. Rather than return to the Otto panel, he opened AI Agent Studio, where these Agentic Workflows get built, tested and configured. He found it among the other workflows already built for him, confirmed the active version, and typed what he wanted: Incident trends tied to payment issues over the last two months.

The Issue Trend Analysis AI Agent reads short description, description, resolution notes, resolution code, category and subcategory. That is how it recognises that two Incidents are related even when nobody worded them the same way.

Running it from the testing screen gave Mark something the chat panel alone does not: the AI Agent decision logs. The Orchestrator handed off, the Agent pulled its stored configuration, validated his two month window against what is supported and only then computed, with each step completing in view under its own status.

Some of you will have taken a finding to Engineering and been asked how you arrived at it, and that is the question this screen answers on your behalf.

For someone who owns the process rather than merely consuming its output, watching an Agent validate its own inputs is what makes the conclusion usable, because everything, both input and output, is visible.

The largest group was order confirmations missing after a successful payment authorization, with root causes pointing at delays updating order status and gateway callbacks arriving asynchronously, late enough that the storefront showed nothing while the bank had already approved the charge. Mark downloaded the analysis, recommendations included, for Engineering.

Afternoon: The Customer Side of the Same Story (Identify Ways to Improve Services)

Mark had ticket evidence, but he did not want to make a service improvement decision on ticket data alone. He asked Otto to analyze recent survey feedback and suggest areas for continuous service improvement.

Many of you will recognise the split here, where ticket data gets reviewed in one meeting and survey results in another, and the two rarely end up in the same room.

Before running, Otto asked him one thing back: which record type should anchor the analysis? It confirmed the scope before it spent any time. Mark answered Incidents, deliberately, because the morning's trend run was about Incident volume and he wanted both views reading the same records.

The Survey Analysis Agent gathered those responses and their linked task data, then analyzed feedback, performance metrics and historical trends, by default across up to 500 records over a three month window.

What came back was a score tied to a specific window, with the pattern underneath it. The dominant complaint was payment and checkout: sessions breaking after multifactor verification, confirmations arriving late enough that customers were unsure whether they had been charged, and retries turning into duplicate authorizations. Each recommendation traced back to language a customer had actually used, and three independent signals now pointed at one thing.

End of Day: Root Cause and a Plan (Investigate Problems)

Mark opened the Problem list and found the record tied to everything he had tracked that day.

He started the investigation from the Problem record and opened the AI Activity panel so he could watch rather than wait blind. The Investigation Agent retrieved the Problem alongside its linked Incidents, the same pattern from that morning, now in one place.

This is where I would point any manager who is unconvinced. The Agent correlated a dozen tickets in the open, where Mark could watch it happen and keep his attention on the conclusion.

If you have ever spent a morning reading a dozen Incidents to find the single thread running through them, that is the hour this gives you back.

The root cause: session and token handling during the multifactor redirect, with session state lost when the customer returned from verification, which is why a completed authorization could still surface as a failed payment. The plan gave Mark three things for Engineering: trace the session and token lifecycle through the redirect, add safeguards against duplicate authorization attempts and validate with regression testing before it ships.

The Same Pattern Underneath All Four

Mark started the morning asking how to distribute work already in front of his team, which led him to a recurring pattern, which sent him to customer feedback, and those signals together led to a Problem investigation with a plan attached. Each workflow handed the next one a better question.

One Day, Four Workflows, One Thread

Each output became the next question

Morning  ·  Help Optimize Team Productivity

Work Allocator AI Agent balances the backlog on capacity, performance and similar past work.

Hands on: a cluster of payment Incidents nobody was looking for.

Late Morning  ·  Analyze Task Trends

Issue Trend Analysis AI Agent groups related Incidents and names the likely root causes.

Hands on: the issue is recurring and preventable.

Afternoon  ·  Identify Ways to Improve Services

Survey Analysis Agent reads the survey responses behind the score and finds the same theme.

Hands on: customers are feeling it, and they say where it breaks.

End of Day  ·  Investigate Problems

Investigation Agent correlates the Problem record and its linked Incidents into one root cause.

Hands on: a resolution plan Engineering can act on.

Four workflows, one payment problem, one working day.

Every workflow in that day followed one path. A manager asks in plain language, the AI Agent Orchestrator finds the right Agentic Workflow and an AI Agent decides which Skills to call at runtime rather than following a fixed pipeline, while progress and reasoning show in the AI Activity panel inside the record, and nothing runs until a human has seen the reasoning.

Two modes exist: supervised, where the manager approves before anything dispatches, and autonomous, where a scheduled job runs it. Sharon Barnes, who hosted the session, framed the choice better than I did. Run it manually until it gives you what you expect, then switch to autonomous.

Why an Agent and Not a Scheduled Job

This question came up on the day, and it is the right one. If a Business Rule, a Flow or a scheduled job already does the job, use it, because they are cheaper to reason about and easier to test.

My working answer: reach for an Agent when the work needs judgment across records that no fixed query can enumerate in advance. Grouping Incidents nobody worded the same way qualifies, and so does correlating a Problem and its linked Incidents into a single root cause. Reassigning a ticket when a field changes does not, and dressing that up as an Agent buys you nothing.

If you can write the query, write the query. Reach for an Agent when the useful query is the thing you are trying to discover.

What You Need to Run These

The baseline is the same for all four workflows.

Requirement Detail
License Professional or Enterprise Plus
Patch level Zurich patch 7, Australia patch 1, or Yokohama patch 13
Application ServiceNow Otto for Platform, version 12.0.12

Then, per workflow, the role to grant and the data each one reads.

Workflow AI Agent Workflow role Set this up first
Help Optimize Team Productivity Work Allocator sn_uxc_gen_ai.platform_ai_help_allocate_work
plus itil
Add the manager to the assignment groups being evaluated
Analyze Task Trends Issue Trend Analysis sn_uxc_gen_ai.platform_ai_analyze_trnds
plus itil
Configure the Group Action Framework on the table you want analysed
Identify Ways to Improve Services Survey Analysis sn_uxc_gen_ai.platform_ai_improve_services
plus itil
Confirm Assessment records are linked to your task tables
Investigate Problems Investigation sn_uxc_gen_ai.platform_ai_problem_investigator
plus itil
Link the relevant Incidents to the Problem record

Grant all three roles. now_assist_panel_user gets the manager into the panel, the workflow role in the table above lets them run that specific workflow, and itil or an equivalent role has to be on the workflow's approved list so it can read and update the task records. If someone can see the panel but not the workflow, check the workflow role first.

Scope your first run. For Investigate Problems, a context limit applies to all generative AI skills, and a Problem carrying a large number of related Incidents can exceed it. The documented guidance in that case is to run the workflow on a different Problem record. For Analyze Task Trends, the time frame you can request is capped by a configuration value that defaults to three months, so you can ask for a shorter range but not a longer one.

Key Takeaways

  • The value is in the sequence. Any one of these four saves a manager time. Run in sequence, they turn a morning of triage into a root cause and a plan by the end of the day, because each one sharpens the question the next one answers.
  • Watching the reasoning is the feature. The AI Agent decision logs and the AI Activity panel are what let a Process Owner trust a conclusion enough to take it to Engineering.
  • Your data decides where you start. Analyze Task Trends reads closed records grouped by the Group Action Framework. Identify Ways to Improve Services reads Assessment records linked to task tables. Start with the workflow whose inputs you already have, rather than building data first.
  • Supervised first, autonomous later. Both modes ship, so run supervised until the recommendations match what you would have decided yourself, then move the workflow to a scheduled job.

Getting Started

  1. Check the baseline. Confirm your license, patch level and ServiceNow Otto for Platform version against the first table above before planning anything else.
  2. Open Agent Advisor in the AI Admin Center. It assesses your instance and points at where out of the box Agents can help and where something custom is warranted. Start there rather than guessing which workflow fits.
  3. Pick the workflow your data already supports, using the last column of the second table, because this is the step that decides whether your first run returns something useful.
  4. Grant both roles to one pilot manager. The panel role and the workflow role, plus assignment group membership for work allocation.
  5. Run it supervised, from AI Agent Studio first. The testing screen exposes the decision logs, which is where you learn how an Agent reaches a conclusion before anyone in the business sees it.
  6. Compare the recommendation to your own judgment. Do that several times on real records. When they agree, you have what you need both to move the workflow to autonomous and to make the case internally.

Frequently Asked Questions

These came up during the session.

What do I need in place to run this?
A Professional or Enterprise Plus license, an instance on Zurich patch 7, Australia patch 1 or Yokohama patch 13, and the ServiceNow Otto for Platform app at version 12.0.12.

 

Some of this looks a lot like process mining. How do they relate?
They answer different questions, in that process mining shows you how a process runs end to end while these workflows take a specific bounded problem and reason across the records behind it. Agent Advisor, in the AI Admin Center, is the practical starting point: it looks at your instance and points at where out of the box Agents apply.

 

Does the Agent only list Incident numbers in the Otto panel, or can I see the detail while I evaluate the recommendations?
Both, depending how you trigger it. The Otto panel is the default, and you can also add a UI action to the list or form so that clicking it surfaces the detail in the AI Activity panel alongside the recommendation.

 

What handles a group of similar Incidents, such as multiple network issues in one location or slowness on a single application?
Analyze Task Trends covers exactly that. It groups related records and shows how they connect, whether that is a shared location or one application degrading for many users, and names the likely root causes.

 

With Investigate Problems, is it kicked off by pressing a button, and the Agent takes over from there?
Yes, and there are two ways to start it with no manual work in between. Give Otto the Problem number or click the UI action in your workspace, and from that point the Agent fetches the Problem record and every related Incident, then does the analysis.

 

Can these run without a person approving each time?
Yes. Supervised mode holds for manager approval before anything dispatches while autonomous mode runs on a scheduled job, and running supervised until you trust the output before moving to autonomous is the path I would recommend.

Resources

Tell Me the Workflow You Wish Existed

This is the question I ran out of time for on the day. Think of the task that still eats your week, then name the workflow that would take it off you. I would rather hear your version.

See Upcoming Platform Academy Sessions

Already run one of these four workflows on your own instance? Tell us in the comments how the recommendation compared to the call you would have made yourself. I read every one.