A practical guide to what AI Agent Advisor is, when to use it, and what it's actually worth

AI Agent Advisor reads the records your teams have already closed, groups them into recurring problems, estimates what each one costs you, and matches it to agents and tools that already exist on the platform. This guide covers what it does, what it needs before it will run, how to read what it produces, and the issues that come up most often.

1 · What AI Agent Advisor does

Choosing what to automate first usually takes weeks of workshops and produces a shortlist nobody can defend with numbers. AI Agent Advisor answers the same question from your operational data instead, and it answers three things:

•

What should we automate first?

•

What is the prospective return from automating it?

•

Which existing agents and tools already fit, and what has to be built?

A note on names

AI Agent Advisor lives inside what used to be called Now Assist Center , now AI Admin Center. Documentation and older articles use both names. Same application, new label.

Treat it as an intake process, not a report

AI Agent Advisor generates candidate agents from raw data. Whether that becomes a real roadmap or a pile of duplicate, poorly named agents depends entirely on whether someone reviews each opportunity before it becomes a build. Every opportunity is a candidate requiring review, not a decision already made.

Not to be confused with Process Mining

AI Agent Advisor is for discovering where to start with automation. Process Mining is for diagnosing why an existing process is underperforming.

The three phases

PHASE 01

Mine

AI-based clustering groups similar tasks, extracts intents, and identifies the resolution steps that are consistent across each group.

In: closed records

Out: intent clusters

→

PHASE 02

Match

Maps each resolution step to existing ServiceNow AI agents, workflows, and tools, producing a solution blueprint with pre-built options already identified.

In: resolution steps

Out: solution blueprint

→

PHASE 03

Make

Integrates with AI Agent Studio to create and deploy agents. Matched tools are added automatically, and a dataset is generated from the source records for testing.

In: chosen opportunity

Out: draft AI agent

How matching works

Matching runs primarily on tools —the specific capabilities each agent exposes—because agent descriptions tend to be broad. Agent proficiency descriptions are a secondary signal. Each resolution step is matched to the most relevant tools first, then the agents those tools belong to are surfaced.

Three consequences:

•

Installation does not limit matching. All available out-of-the-box agents and tools are scanned whether or not they are installed. If a step maps to a tool from an agent you do not have, you are prompted to install it before proceeding.

•

Licensing is checked. A tool you are not licensed for will not be added to a generated agent, and the interface surfaces which tools need an additional install or license.

•

An unmatched step is a finding. It is flagged as needing a custom tool—a subflow, a custom skill, or a custom agent. That is your build scope, identified before development starts.

When to run it

Window 01

Evaluating the capability

Run against a clone with representative data to replace weeks of discovery workshops, and to verify that the out-of-the-box tools serve your organization.

Window 02

During implementation

Run against a clone of production to get a prioritized automation backlog within hours, and start agent creation from generated drafts rather than a blank form.

Window 03

After deployment, on a cadence

Review results regularly to identify new opportunities as your data shifts. Feed output into adoption plans and roadmaps, then re-run and compare coverage over time to track improvement. This is the window most teams skip.

2 · Prerequisites

Everything that has to be true before a run will succeed. The most common cause of a failed analysis is a condition in this section that nobody checked.

Platform and licensing

Requirement

Detail

Platform version

Zurich Patch 10 or Australia Patch 3, minimum

License

A license that includes Now Assist

Instance types

Production and sub-production

Companion application

Install AI Admin Center for the full experience. AI Agent Advisor is installed automatically as part of it.

Application version

1.3.2 or later to use all tables derived from the task table. On an earlier version, upgrade to the latest patch for Zurich or Australia.

Dependencies

Installed automatically and included in the license: Insights Clustering Utils, Group-Action Framework, and AI Search

Patch and application dependencies change between releases. Check the required applications table in the troubleshooting guide for current values rather than relying on a version number in any article, including this one.

Roles

Access problems are almost always a single missing role.

Role

Needed for

sn_na_center.nac_admin

Opening AI Agent Advisor configuration from AI Admin Center. This is the role that resolves most access-denied reports.

sn_na_center.admin

or sn_na_center.user

Access to AI Admin Center itself

sn_agent_miner.app_admin

Must be present on the agent-miner-svc-account user for executions to run. Also the role to extend to provide access to more tables.

The third sits on a service account rather than on a person, which makes it easy to overlook. If executions never start, check it first.

Data requirements

Two conditions gate everything, and together they explain most failed runs.

At least 500 resolved or closed records in the task-derived table you want analyzed?

If no
The analysis cannot run. This is a hard minimum and cannot be modified. Configure the record filter to increase the number of included records, extend the date range, or choose a table with more history.

Do those records have populated work notes or comments?

If no
Records without this content cannot yield meaningful intent extraction. The run may complete and produce nothing useful.

Both conditions met?

Proceed
Configure the data source and run it. There is no word count enforced per record—the system looks at the entirety of each record and determines which to sample from. Populated notes matter more than long ones.

Any table derived from the task table is supported, including custom tables and custom fields.

Not reaching 500 records is itself a useful finding

If you cannot assemble 500 qualifying records with populated work notes, that result is information rather than a dead end. It indicates that record-keeping practice needs attention before agentic automation will land well anywhere, which is a more valuable conversation to have early than a list of opportunities would have been.

3 · Running it end to end

AI Agent Advisor runs automatically once installed, and then again every 90 days. An Execute Now button on the settings page runs it immediately.

Configuration in brief

The setup form is a single page covering the table and fields to read, the run frequency (30, 60, or 90 days), a record filter, and the savings inputs. The product documentation covers the walkthrough in full, so rather than repeat it, here are the four things worth knowing that the documentation does not emphasize:

•

The filter panel shows a live record count. Number of records found updates as you change conditions, so you can confirm you are above 500 before saving rather than after a failed run.

•

Field selection determines narrative quality. Choose the free-text fields, not only the short ones—close notes and description are what intent extraction actually reads.

•

The table cannot be changed later. On a saved data source the table name is read-only, so a different table means a new data source. Fields and filters remain editable.

•

A filter does not transfer between tables. State values differ from one table to another, so a condition set that returns thousands of records on one table can return zero on another. Check the live count every time you point at something new.

Watch the execution stages

Execution progress displays stage by stage, and a failure at a given stage points to a specific class of problem. This makes the progress panel the fastest diagnostic available, and it is not documented elsewhere.

Stage

What a failure here points to

Checking instance readiness

Pre-flight checks covering licensing, data volume, access, and extraction. A stop here is configuration or permissions rather than data quality.

Analyzing root causes and intents

Extraction is reading record narrative, so failures here are about field-level content rather than record volume—sparsely populated fields, or a filter returning fewer usable records than the raw count suggested. Readiness passing does not guarantee this stage will.

Creating automation opportunity groups

The clustering step, and the most common place to fail. Insufficient volume or insufficient narrative content both surface here.

Generating resolution step

Clusters formed but consistent steps could not be derived from them.

Matching AI Agents

Matching depends on AI Search. Check that AI Search is enabled and that indexing has completed.

Matching tools available on instance

Reconciliation against what is installed and licensed. Gaps here appear later as missing tools on a generated agent.

Expand the readiness sub-checks

Stage one expands into six sub-checks—skill licensing, raw data, filtered data, data with ACLs, point-of-view extraction, and machine-learning solution table access—and each carries a Detail message explaining what it found. When a run fails, open the chevrons and read which check stopped rather than guessing. Note that the raw, filtered, and access-controlled record counts are verified separately and each can be smaller than the one before it, so the remedy depends on which of the three actually stopped.

From opportunity to build

Review the opportunities using the signals in section 4, then hand off. The path depends on solution type:

•

Pre-built opportunities are adopted rather than generated. The panel shows the matched agent with its state and full description, including its in-scope and out-of-scope conditions, which are worth reading before you activate. If the required plugin is not installed, a banner says so and the Review and activate in AI Agent Studio button stays disabled until you install it. Where the agent is already active, the button instead reads Manage in AI Agent Studio.

•

Custom opportunities are generated. Continue in AI Agent Studio creates the agent with name, description, role, and steps pre-populated from the resolution step list, and matched tools added automatically. The conversational experience in AI Admin Center is a second route to the same outcome. Opportunities also surface as insights in AI Control Tower.

The handoff pre-populates the agent; it does not lock it. You still own triggers and channels, security controls, instruction refinement, naming against your own standards, any step flagged as unmatched, and evaluation. You will also need to decide whether the agent communicates over text chat or voice—voice agent tools are included during matching, and Voice Agent is available as an option when you generate.

Two things that catch people out

Install before you generate. Matched tools are only added if the associated agent is installed. If the opportunity page prompts you to install an agent and you proceed without doing so, the tool will not be added.

Editing a step re-runs the opportunity. The interface states it directly. Read the example records, decide every change you want, and apply them together rather than adjusting one step at a time.

Evaluate before deployment

When an agent is generated, a dataset is also created containing all the records identified as having an intent matching that opportunity. Open the automated evaluation tool and the dataset is already selected, so no manual preparation is needed. This lets you validate that the agent resolves the tasks that triggered the cluster in the first place, using real records, before committing to a production deployment.

4 · Reading the results

The strongest opportunities are recurring, repeatable problems. The weakest ones can look identical in the list, so this section is about telling them apart.

Each row carries the generated name, its status, the solution type, the source data source, estimated annual cost and time savings, an estimated deflection rate, and the total issue count. Two of those columns do most of the work: Solution type and Total issues.

Solution type is the column to read first

Pre-built AI Agent

A shipped agent already covers this. Install, review, and activate. Lower effort and lower risk, and the natural place to start.

Custom AI Agent

Nothing off the shelf covers it. AI Agent Advisor has produced a specification, but the build is yours. Higher effort, and where the design work sits.

A list dominated by custom entries tells you your recurring problems are specific to your organization. That changes the work from adoption to development, and it should change your estimate.

ServiceNow's guidance on sequencing is direct: focus on the opportunities with the greatest volume of records for the highest return. Volume indicates how frequently an issue has occurred, and therefore how much of it is left to automate.

Use the confidence score and the match explanation

Opening an opportunity gives three tabs: the resolution steps, the example records behind the cluster, and the matched agents. Each step shows its matched agent or tool, a confidence score for how well it fits, and an explanation of why that match was selected. Together these are what let you overrule a match intelligently rather than on instinct.

Treat a low confidence score as mandatory review, not automatic rejection. The match may well be right, and the explanation will usually tell you whether it is. A zero on the matched agents tab is similarly informative rather than broken—it means no existing agent covers this and you are looking at a genuine custom build.

Verify the cluster before acting on it

Review the example records within a cluster to confirm the generated intent accurately represents the record group. A cluster driven by an outage, a seasonal spike, or a single bad release can show high volume without representing a recurring pattern, and it will sit high in the list looking like a strong opportunity.

If the records read like the same problem happening repeatedly for the same reason, it is a real candidate. If they cluster around one date range or one root cause since fixed, it is not.

What happens to opportunities you do not act on

Nothing is lost by leaving an opportunity alone. It stays in the list and keeps resurfacing on subsequent runs, with its record count growing as more matching records accumulate. That growth is a signal in itself: a problem climbing the list over successive runs is getting worse.

Re-running does not simply append to previous results. Each run reflects the current state of your data, so an opportunity you have addressed should shrink or disappear as those records move out of the window, while new patterns appear alongside whatever remains open. Deprioritizing is therefore a cheap, revisitable decision, and you do not need a separate register of rejected opportunities.

Where the savings figures come from

The Savings projections panel takes two inputs, each with a recommended range shown inline: hourly labor cost in USD (recommended 15 to 30 per hour) and active handling time rate (recommended 10% to 25%), the share of a record's total open time actually spent working on it. The formulas are stated in the interface:

`Estimated time saved = Active handling time rate x Total open hours

Estimated cost savings = Total open hours x Active handling time rate
                          x Hourly labor cost`

The panel shows a worked example: for 10,000 total open hours at 10% and 15 per hour, that is 1,000 hours and 15,000.

The savings figure is driven by open hours, not frequency

The input is total open hours , not record count. Two opportunities with identical record volume produce very different savings if one sat open for days and the other closed within the hour.

So a low-volume problem whose records sit in a queue for a long time can outrank a high-volume problem that gets closed quickly. Neither ranking is wrong—they answer different questions. But if you read a savings figure as a recurrence measure, you will mis-sequence your backlog. Read Total issues as a separate signal.

Tune the inputs before presenting any figure

These values are defaults until you change them. Take the time to tailor them to your organization. The active handling time rate is the one most often misread: it is a share of open time, not an estimate of minutes per record, and moving it from 10% to 25% multiplies every figure on the page by two and a half.

A worked example

Abstract guidance on clustering is hard to act on, so here is what a strong result and a weaker one look like side by side.

A service desk has 1,400 closed incidents over the last quarter, loosely tagged under access issues. Mine clusters 340 of them into a tight group. The intent comes back consistently as a user locked out after password expiry, and the resolution steps in the work notes are near-identical across the group: verify identity, trigger a reset, confirm access restored.

Match maps that cluster almost entirely to the existing tools on an out-of-the-box agent covering password reset, with a high confidence score on each step. High volume, near-complete match, low build effort—a strong first candidate.

Now the contrast. A second cluster holds 60 records around a niche vendor-integration failure, and three of five resolution steps come back unmatched. Same analysis, same run, very different verdict: fewer records and substantially more to build. Still a legitimate opportunity, just a later one.

Sequencing the backlog

Those two clusters sit in opposite corners of the same grid. Two variables decide where an opportunity belongs: how often the problem recurs, and how much of the solution already exists. Read Total issues for the first and Solution type for the second.

Low match coverage

(custom build needed)

High match coverage

(pre-built available)

High record volume

Build estimate
Worth doing, but a development investment rather than a quick win. The unmatched steps are your scope, identified before anyone opens a form.

Start here
Frequent problem, solution largely exists. Move these first and use them to build confidence for the rest.

Low record volume

Deprioritize
Limited return and high effort. Leave it in the list and let later runs show whether volume is growing.

Quick, later
Easy to adopt, limited payoff. Useful once the higher-volume items are moving, or as a first exercise for a new builder.

5 · Troubleshooting

Failed pre flight checks

Signal

The data source is marked Failed to generate, and stage one reads Checking instance readiness - Failed pre flight checks with no later stage started.

The submission itself succeeded—you may even have seen a confirmation that the mining job was submitted—but the run stopped before any analysis began. Expand the sub-checks to see which one failed, and use the Learn more link on the panel. Most commonly this is record volume, so check the filter's record count first.

Zero records found on a table that clearly has data

Signal

The filter panel shows Number of records found: 0, and every run for that data source fails.

The filter is not matching anything on that table. This happens most often when a condition set is reused from another data source: state values and field names differ between tables, so a filter that returns thousands of records against one table can return none against another. Rebuild the conditions against the table's own values and confirm the live count before saving.

Insufficient data

Signal

The run fails early, or the record count is below 500.

The minimum applies to the records inside your filter, not the records in the table. A filter scoped to a short recent window on a low-volume table will fail even when the table itself holds far more. Configure the record filter to increase the number of included records, and confirm the records have populated work notes or comments—volume alone is not sufficient. See KB3144183.

Extraction failed on mandatory fields

Signal

Every readiness sub-check passes green, then the run stops at Analyzing root causes and intents with an extraction error naming the POV extractor and a record count against the 500 minimum:

`Analyzing root causes and intents - Error: [PovExtractor] execute ::
Extraction failed Error: Check POV records with mandatory fields failed.
147 out of 4930 records have mandatory fields issue (minimum required: 500).
Check data quality or modify mandatory fields configuration.`

This is the most instructive failure in the product, because it shows that passing pre-flight is not the same as having extractable data. All six readiness checks cleared, including the POV Extraction Check, and there are nearly 5,000 records in scope—yet extraction still could not assemble 500 usable ones.

The cause is field-level rather than volume-level. Records are present, but the fields extraction depends on are not adequately populated across enough of them. The message names both remedies itself: check data quality , or modify the mandatory fields configuration. In practice that means confirming that the free-text fields selected on the data source are genuinely filled in across the record set, and reconsidering the field selection if they are not. A table where most records carry a short description but little else will produce exactly this error.

Note that the count in the message is reported against the 500 minimum, so read that figure rather than the total in scope—the total tells you nothing useful here. KB3144107 covers extraction failures, and KB3144108 covers the closely related case of extraction returning too few records despite a large source set.

Intent clustering failed

Signal

The run stops at Creating automation opportunity groups.

Readiness and extraction passed, so the clustering step itself could not form groups. Start with record volume and narrative quality inside the filter. The error message is generic, so the useful detail is in the execution logs on the settings page. KB3144186 covers this specifically.

Execution stuck in progress

Signal

A run displays In progress indefinitely and new runs will not start.

Only one execution can be in progress at a time, so a stuck run blocks everything behind it. KB3144105 documents the supported cancellation procedure. Two points from it are worth knowing in advance: the execution record's status must be set to Failed or new executions will not trigger, and the interface may continue to display In progress until the execution summary is updated as well.

Resolution steps never load

Signal

A custom AI agent opportunity opens, the tabs and the step controls render, but the resolution steps themselves sit on a loading indicator and never appear.

The opportunity exists and its example record count is populated, so the cluster was formed; it is the step content that is not returning. Re-running the mining job for that data source is the practical first move, since it regenerates the opportunity and its steps. If the steps still do not load after a clean run, capture the opportunity and raise it with Support rather than continuing to re-run.

Run completes but no opportunities appear

Signal

All stages complete, empty results.

Typically extraction returning nothing usable despite a healthy raw record count. The records exist, but no usable content came out of them. Review narrative content quality and the fields selected on the data source. See KB3144189.

Agent matching failed

Signal

The run reaches Matching AI Agents and stops.

Matching depends on AI Search. Either it is not enabled or indexing has not completed. Confirm both before re-running rather than retrying blind. Indexing that never completes is documented separately in KB3144192.

Tools missing from a generated agent

Signal

A tool visible in the match results is not attached to the generated agent.

The source agent is not installed. The platform flags which agent is needed. Once it is installed you can return and add the tool to the generated agent manually.

The activate button will not click

Signal

A pre-built opportunity looks ready, but the activate button is disabled.

The required plugin is not installed, and a banner above the agent card says so with a link to Application Manager. Install the plugin and return to the opportunity.

Only incident, case, and interaction are available

Signal

No option to add another task-derived table as a data source.

Support for all tables derived from the task table requires application version 1.3.2. If that version is not available to upgrade to, move to the latest patch version for Zurich or Australia and try again. See KB3144102.

Access denied opening the configuration

Signal

AI Admin Center opens but the AI Agent Advisor configuration does not.

Check sn_na_center.nac_admin first. If executions are failing rather than the interface, check sn_agent_miner.app_admin on the service account instead. See KB3144098.

Where to find the error

Error logs are on the AI Agent Advisor settings page. Review the troubleshooting guide first; if the answer is not there, log a case with Support. The full article list is in section 7.

6 · Leading practices

Before you run it

✓

Verify platform version, license, and the three roles first.

✓

Check record count and work-notes coverage on the target table. This is the best single predictor of whether a run will succeed.

✓

Use the live Number of records found count while building the filter, so a data shortfall never surfaces as a failed run.

✓

Build the filter against the target table's own field and state values rather than reusing a condition set from another data source.

✓

Select the free-text fields, not only the short ones. Close notes and description are what intent extraction reads.

✓

Run against a clone with representative data.

When you review the results

✓

Tune both savings inputs to your own figures before presenting any estimate.

✓

Read Total issues as a separate signal from savings. Savings is driven by open hours, not frequency.

✓

Start with the highest-volume opportunities. That is where near-term return concentrates.

✓

Read Solution type before estimating effort. Pre-built means adopt; custom means build.

✓

Review the example records in a cluster to confirm the generated intent represents the group.

✓

Read the confidence score and match explanation on each step. Treat a low score as mandatory review, not automatic rejection.

✓

If results feel scattered, increase the number of included records before concluding the analysis is not working.

✓

Check licensing before committing to a use case. Matching covers the platform regardless of what is installed or licensed.

✓

Expand the readiness sub-checks and read the detail messages before debugging anything else.

When you build

✓

Install any prompted agent before generating, or matched tools will not be added.

✓

Batch your step edits—each one re-runs the opportunity.

✓

Edit resolution steps where you know better than the data, then re-match.

✓

Read a pre-built agent's in-scope and out-of-scope conditions before activating it.

✓

Put a review gate between opportunity and build, with someone accountable for naming and de-duplication. Generated names come from clusters, so without this you accumulate near-identical agents nobody owns.

✓

Have a second person confirm tool selection, naming, and instruction structure against your own build standards before a builder inherits the work. The generated blueprint is a starting point, not an approved design.

✓

Run the automated evaluation before production. It tests against the records that justified building the agent.

After go-live: why using it matters more than running it

The return does not come from building the agent. It comes from how much that agent actually gets used against a real, recurring problem.

An agent built against a one-off spike has a ceiling on its value however well it is tuned, because there is nothing left to automate once the spike passes. An agent built against a genuinely repeated operational problem keeps paying out every time that problem recurs. That is why picking the right use case matters more than almost anything else in this process —and it is exactly the job the volume ranking is doing, surfacing problems that keep happening rather than ones that happened once and got noticed.

Once you have picked a real recurring pattern, the built-in savings estimate is a reasonable number to prioritize with. It is not the number to present as final, because it is driven by whatever inputs were left in the savings panel.

Take the 340-record password-reset cluster from the worked example in section 4. Suppose those records sat open for an average of ten hours each— 3,400 total open hours. At a 10% active handling time rate , that is 340 hours a year, and at a loaded cost of 30 per hour , roughly 10,200. A useful sanity check falls out of that arithmetic: at a ten-hour average open time and a 10% rate, you are claiming about one hour saved per record. If that does not sound plausible to the people who work these records, the inputs need revisiting before the estimate goes anywhere.

That is a meaningful, defensible number once your own figures are in. But value scales with usage, not with the estimate. The more the agent is actually invoked against that same recurring pattern, the more the figure compounds. The estimate at discovery time is a projection of that; it is not proof of it.

A few things worth doing once an agent from this process goes live:

✓

Set a baseline in the first 30 days. Capture usage and resolution-time patterns immediately after go-live, so there is a genuine before-and-after later.

✓

Review monthly with the same stakeholders who saw the original opportunity, not only with the engineering team.

✓

Correlate usage against the measure you originally targeted , not raw consumption.

✓

Investigate usage that does not match expectations in either direction. A spike can mean strong adoption or a misconfiguration; a flat line can mean work is not reaching the agent.

✓

Re-run on a cadence and compare coverage over time rather than treating any single run as final.

✓

Align that cadence to a reporting cycle you already run , so new opportunities surface alongside your existing usage and value data.

An agent that gets built, evaluated, and then never checked again is a sunk cost with an unproven claim attached to it. An agent tracked against the original opportunity—same records, same baseline, real usage data—is the difference between a project and a repeatable practice.

Measurement is what makes the next run worth doing

That tracking discipline compounds beyond the agent itself. The more consistently you can show what the last opportunity actually returned, the easier it is to justify prioritizing the next one—which is what turns a sequence of individual builds into a programme with its own momentum.

Keep in mind

This is a generative AI capability and its output is probabilistic. Clusters, intents, resolution steps, and estimates are all evidence to be reviewed by people who know the work, not conclusions to be deployed. Keep a person in the loop, particularly where the automation touches something consequential.

From backlog to confidence

AI Agent Advisor tells you what to automate and how much of it already exists. Whether the estimate it produces is reliable enough to act on is a judgment made at discovery time, and it stays a judgment unless someone keeps measuring after go-live.

It answers the first question in an AI programme: where do we start? It answers it from evidence rather than opinion, and it produces a draft agent and a test dataset along the way. It does not answer the second question—whether what you built actually works. That is the evaluation loop, and the dataset AI Agent Advisor generated is where that loop begins.

Your data already indicates what to automate first. This is how you ask it, and the review you do afterwards is what makes the answer worth having.

7 · Availability and resources

Availability

Support for GCC and for domain-separated environments differs from standard instances. Confirm the current position with ServiceNow before planning a deployment in either, and check the availability documentation for regulated and self-hosted environments.

Data handling

AI Agent Advisor follows the same data-handling model as other Now Assist capabilities: prompts and responses are processed in memory rather than stored in ServiceNow data centers, and temporary data is discarded once the interaction concludes. Data sharing for model improvement is a separate, optional programme with an opt-out available in Now Assist Admin.

Detailed architecture, data flow, and regional processing specifics are published in ServiceNow Support articles, which require Support access to view. The Now Assist Responsible AI, Data Handling and Security article is the index to them. If data residency or retention specifics bear on your compliance position, review those articles at the start of a deployment and raise anything they do not cover with Support.

Troubleshooting articles

Symptom

Start here

General starting point

KB2931703

Access denied when opening in AI Admin Center

KB3144098

Not visible, will not install, or will not upgrade

KB3144102

Execution will not start or cannot be scheduled

KB3144104

Execution stuck in progress, and how to cancel it safely