Month: October 2026

Faster Generic Inquiries in Acumatica 2026 R2: Grouped Tables, Query Design, and Dashboard Performance

Slow Generic Inquiries in Acumatica are usually improved by reducing the work performed by the base inquiry before changing how the results look. Start with the business question, select only the required data sources and fields, join tables on the correct keys, filter early, limit unnecessary totals and rows, and test with representative data. Acumatica 2026 R2 grouped table views can make results easier to explore, but they use an existing Generic Inquiry as their data source and do not automatically correct an inefficient query.

This guide explains how to diagnose Acumatica Generic Inquiry performance without sacrificing the meaning of the report. It covers Generic Inquiry design, 2026 R2 grouped table views, dashboard refresh behavior, benchmarking, reconciliation, deployment controls, and the point at which a workload belongs in a different reporting architecture. The intended audience includes Acumatica administrators, functional consultants, report designers, developers, SQL specialists, finance leaders, operations managers, and quality assurance teams.

Table of Contents

Why Generic Inquiry performance is a business issue

How an Acumatica Generic Inquiry processes data

What changed with grouped table views in 2026 R2

Why grouped tables do not replace query optimization

Define the business question before editing the inquiry

Build a performance baseline that can be repeated

Recognize the main Generic Inquiry performance patterns

Choose the smallest correct set of data sources

Design table relations without multiplying records

Use conditions and parameters to reduce the working set

Control displayed rows and page size deliberately

Sort only when the result requires an order

Group and aggregate without changing the metric

Manage formulas and calculated fields carefully

Configure grouped table views for useful analysis

Improve dashboard performance at the consumption layer

Treat nested Generic Inquiries as dependencies

Prevent duplicate and missing results

Use a disciplined before and after test method

Worked test case for open sales orders

Worked test case for grouped accounts payable analysis

Worked test case for an executive dashboard

Reconcile performance changes with business totals

Deploy Generic Inquiry changes safely

Monitor performance after release

Know when a Generic Inquiry is the wrong tool

Generic Inquiry performance review checklist

Frequently Asked Questions

Sources

Why Generic Inquiry performance is a business issue

A slow inquiry is not merely an inconvenient screen. The same Generic Inquiry can feed a list, export, pivot table, dashboard widget, integration, OData request, AI feature, or user workflow. A design that performs adequately for one analyst can become expensive when it is placed on a dashboard opened by many users or refreshed throughout the day.

The business impact also depends on when the inquiry runs. A ten-second inquiry opened once during a monthly review may be tolerable. The same inquiry used by an order desk after every customer call can delay work. If several dashboard widgets rely on broad inquiries and refresh at short intervals, the cumulative load may affect users who are entering orders, releasing documents, or reviewing inventory.

Performance therefore needs an explicit service expectation. The team should identify who uses the inquiry, how often it runs, how current the data must be, how many rows users actually need, and what decision depends on the result. Without that context, optimization often removes useful detail or shifts work to another part of the system.

A sound performance review protects two outcomes at the same time:

1. The inquiry returns quickly enough for its operational purpose.
2. The result still represents the correct business population, grain, and calculation.

The second condition is essential. A fast inquiry that omits valid documents, duplicates amounts, or changes the definition of an open order is not optimized. It is wrong.

Back to TOC

How an Acumatica Generic Inquiry processes data

An Acumatica Generic Inquiry is a configurable data request built on data access classes, commonly called DACs. The designer selects data sources, defines relations, applies conditions and parameters, specifies grouping and sorting, and chooses fields for the result grid. Acumatica then generates the request needed to retrieve and present the data. The official Creation of a Generic Inquiry documentation describes this sequence and emphasizes that the design depends on the organization's business needs.

It is useful to separate the work into four layers.

Business definition

This layer defines the question, population, grain, measures, and security. An inquiry may answer "Which sales orders are open" or "What is the total open order value by customer and week." Those are different questions. They require different rows, fields, grouping, and validation.

Query definition

This layer includes DAC selection, relations, conditions, parameters, formulas, grouping, sorting, and limits. Most material performance problems begin here because these settings determine how much data must be joined, filtered, calculated, sorted, and returned.

Presentation definition

This layer controls how users see the result. In 2026 R2 it can be a table, pivot table, or grouped table view. Presentation can reduce visual clutter and help users reach the right level of detail, but it cannot make an overbroad or incorrectly joined base inquiry logically correct.

Consumption pattern

This layer covers dashboards, exports, OData consumers, automations, and repeated interactive use. The same query design creates different total load depending on refresh intervals, user count, filters, and concurrency.

The distinction prevents a common mistake: changing a widget or grouped view while leaving the expensive base request untouched. Diagnose each layer, then change the lowest layer that actually causes the problem.

Back to TOC

What changed with grouped table views in 2026 R2

Acumatica 2026 R2 adds grouped table views as a formal data representation for Generic Inquiry results. A grouped table organizes records into an expandable hierarchy and can show summarized information together with underlying detail. According to Acumatica's Data Views General Information, the available representations are Table, Pivot Table, and Grouped Table.

The feature must be enabled through Grouped Table Views in Generic Inquiries on the Enable or Disable Features form, CS100000. Once enabled, users can create personal grouped views for inquiries they can access. Administrators can create shared views and can make an appropriate shared view the default for all users.

A grouped table can contain multiple group levels. Each level can have its own fields, sort order, aggregate values, and display settings. The details section can retain the underlying records, so a manager can start with a summary and expand a group when a total needs explanation. The official Grouped Table configuration guidance explains how to create and configure these views.

For example, an accounts payable inquiry can be grouped first by vendor and then by financial period. A group level can display total and average document amounts, while the details section retains individual bills and adjustments. Acumatica's grouped table activity uses this pattern to demonstrate a shared default view.

Grouped views can improve usability in several ways:

• Users can begin with summaries instead of scanning a flat result set.
• Multiple analytical views can reuse one governed inquiry.
• The underlying details remain available for investigation.
• Administrators can standardize a shared view for a role or process.
• Personal views let individual users organize the same governed data without cloning the inquiry.

These are meaningful improvements, especially where teams previously created several near-duplicate inquiries to present the same facts at different levels.

Back to TOC

Why grouped tables do not replace query optimization

A grouped table is a view of one Generic Inquiry's results. Acumatica states that each data view uses an existing Generic Inquiry as its data source and that the inquiry's parameters and filters apply to every representation. That means the grouped table and the base inquiry must be evaluated together.

If the underlying inquiry joins unnecessary DACs, returns years of history, calculates expensive formulas for every row, or multiplies records through an incorrect relation, a grouped presentation does not remove that work by definition. It may make the output easier to read, but the query still needs to produce the source data required by the view.

The practical rule is simple:

Use grouped table views to improve how people explore a correct, appropriately scoped inquiry. Optimize the base Generic Inquiry to reduce unnecessary data work.

This distinction also protects the business meaning of the result. Moving a metric into a grouped view may change where aggregation occurs. A detail inquiry grouped for display is not always equivalent to an inquiry designed to return one row per business entity. If a dashboard needs only one total, it may be better to build a narrowly scoped source inquiry than to return a large detail population and aggregate it later.

Before adopting a grouped table as a performance change, answer four questions:

1. Does the base inquiry return fewer rows or perform fewer calculations after the change?
2. Does the grouped view merely collapse rows visually, or does it change the data request?
3. Are the same filters and parameters applied in both the baseline and revised tests?
4. Do totals and distinct business keys reconcile at every group level?

If the first answer is no, describe the grouped table as a usability improvement rather than a query optimization.

Back to TOC

Define the business question before editing the inquiry

The fastest useful Generic Inquiry is the smallest correct request for a defined decision. Performance work should therefore begin with a one-sentence business question, not with the Generic Inquiry screen.

Consider the difference between these requests:

• List all open sales order lines.
• Show open sales order value by customer.
• Show orders ready to ship today by warehouse.
• Count overdue shipments for an executive dashboard.

The first request needs line-level detail. The second needs a customer-level measure and may not need every line field. The third needs operational filters and warehouse data. The fourth may need only a narrow population and a count. Reusing one broad inquiry for all four tasks is convenient during prototyping but can be expensive and difficult to validate.

Document the following before changing the design:

• Population: Which records qualify and which must be excluded.
• Grain: What one result row represents.
• Measures: Which amounts, quantities, counts, dates, or statuses matter.
• Dimensions: Which fields users need for grouping, filtering, or explanation.
• Freshness: How current the result must be.
• Audience: Who can see the data and who owns its definition.
• Consumption: Screen, dashboard, export, OData, automation, or another use.
• Acceptance criteria: Required totals, sample records, and response-time target.

This brief is also the basis for reconciliation. If the grain is "one row per sales order," the test must compare distinct orders, not only the number of result rows. If the measure is "open amount," the team must define how holds, cancellations, partial shipments, tax, currency, and released documents affect the total.

Back to TOC

Build a performance baseline that can be repeated

An optimization claim is credible only when the baseline and revised inquiry are tested under comparable conditions. Capture the baseline before editing the inquiry, even when the problem appears obvious.

Use a test tenant or controlled nonproduction environment with representative data. Record the Acumatica version and build, enabled features, database or hosting context, inquiry identifier, filters, user role, and relevant customization packages. Performance observed on a small demonstration dataset cannot predict a production tenant with several years of transactions and concurrent users.

For each test scenario, record:

• Time from request to usable result.
• Number of rows returned.
• Distinct count of the primary business key.
• Key totals or aggregates.
• Selected parameter values and filters.
• Whether record counts and totals were enabled.
• Records per page and Select Top settings.
• Dashboard refresh or cache setting when applicable.
• First-run and repeated-run behavior.
• Any server, database, or application evidence available to the responsible technical team.

Run each scenario more than once. A single result may be influenced by caching, competing activity, or network conditions. For operational comparison, use the same sequence of tests and report the median together with a slower percentile such as the 95th percentile when the sample size is sufficient. These are measurement practices, not Acumatica performance guarantees.

The baseline should include at least one typical case and one legitimate heavy case. A date range covering the current week may represent daily work, while a full financial year may represent period-end analysis. Do not benchmark an artificially narrow filter and then claim that the inquiry is fast for all users.

Back to TOC

Recognize the main Generic Inquiry performance patterns

Most slow Generic Inquiries fall into one or more recurring patterns. Recognizing the pattern helps the team avoid random changes.

Broad population

The inquiry loads far more records than the user needs. Common signs include no required date parameter, an all-branches default, historical closed documents mixed with current exceptions, or a dashboard widget that queries the full table to show one number.

Row multiplication

The result contains duplicate business entities or unexpectedly high totals because a one-to-many relation is joined at the wrong grain. Adding another detail table can multiply existing detail rows. A cross join is especially dangerous because the result size is the number of rows in one source multiplied by the number in the other, as the Generic Inquiry form reference explains.

Expensive presentation work

The inquiry returns many columns, sorts a large population, calculates formulas, loads record counts and totals, or requests an excessive page size. Each operation may be reasonable alone but costly in combination.

Repeated consumption

An inquiry that is acceptable interactively becomes expensive when several widgets, users, or integrations run it repeatedly. Very short dashboard refresh intervals can turn a modest query into a continuous workload.

Incorrect aggregation

The inquiry groups at one level but includes fields or formulas that imply another. The system may need to calculate more than expected, and the output may be misleading even if it loads quickly.

Nested complexity

One Generic Inquiry uses another as a data source, which may itself depend on additional inquiries. Reuse can improve governance, but deep or broad dependency chains make the total work harder to see and test.

Environmental contention

The inquiry design may be sound, but performance changes during imports, releases, integrations, backups, or other heavy activity. Query optimization alone cannot resolve capacity or scheduling problems. The baseline must capture when the slowdown occurs.

Back to TOC

Choose the smallest correct set of data sources

Every data source should have a stated purpose. If the inquiry only needs fields from a sales order header, adding line, shipment, invoice, customer location, and inventory DACs creates work and changes the possible grain. Remove a data source only after confirming that it is not required for a condition, parameter, formula, security rule, navigation link, or result field.

Acumatica's documentation recommends identifying the DACs and fields behind the relevant forms before creating an inquiry. The DAC Discovery guidance explains that users access database data through DACs and that the selected fields become result columns or inputs to the report design.

Use this review sequence:

1. Mark the parent business entity that defines one intended row.
2. List every output field and identify its source.
3. List every condition, parameter, formula, grouping field, and navigation field.
4. Remove fields that no consumer uses.
5. Identify data sources that remain only because of removed fields.
6. Retest the inquiry after each logically related change.

Selecting fewer result columns can improve network transfer and rendering, but the larger gain often comes from eliminating an unnecessary one-to-many source. If a field is needed only for drill-down, consider whether navigation to the source record can replace copying many descriptive columns into the result.

Do not select a base DAC solely because its name looks familiar. Inspect the form field, DAC schema, keys, and relationships. Acumatica documents that DAC key fields can be discovered through the schema browser and recommends key and foreign key fields for relations because they allow faster retrieval. See Discovery of Key Fields.

Back to TOC

Design table relations without multiplying records

Relations determine both performance and correctness. The designer must know the cardinality of each pair: one-to-one, one-to-many, or many-to-many. The order and type of joins also affect which records survive and how many rows the result contains.

Acumatica's multiple data sources documentation explains that sources are paired as parent and child, and the sequence of pairs determines how the system builds the combined data. The Related Tables dialog can propose relationships, but the designer remains responsible for confirming that the relation matches the business question.

Verify complete keys

Many Acumatica documents use composite keys. Joining only on a reference number while ignoring document type, company, branch, or another key component can connect unrelated records. Use the full logical relationship required by the DACs and business process.

Choose the join type intentionally

An inner join keeps only records with a match in both sources. A left join keeps every parent record and adds matching child data when available. Changing an inner join to a left join can recover missing parents, but it can also introduce null child fields. Changing a left join to an inner join may reduce rows while silently excluding valid business records.

Count at the intended grain

Suppose 100 sales orders average five lines and each line has two related allocation records. A header-to-line-to-allocation result can contain approximately 1,000 rows before other relationships are added. Counting rows would not count orders. Summing a header amount across those rows could multiply the value. The correct design depends on whether the intended grain is order, line, or allocation.

Avoid cross joins unless the business case requires them

A cross join combines every row from one source with every row from another. Even small sources can create a large result. Cross joins should be treated as a deliberate analytical operation with a bounded dataset, not a shortcut for an unresolved relationship.

Validate optional relationships

When child data is optional, test parents with no child, one child, and multiple children. This reveals both missing rows and multiplication. Keep a small set of known business records for regression testing after every relation change.

Back to TOC

Use conditions and parameters to reduce the working set

Conditions and parameters are among the most effective ways to reduce unnecessary work, but they serve different purposes. A condition defines what the inquiry includes by default. A parameter lets the user supply a value in the selection area and can narrow the result for a particular task.

Acumatica's condition configuration documentation shows how conditions combine fields, operators, values, parentheses, and And or Or logic. Treat the Boolean expression as code. A misplaced bracket or broad Or clause can change both performance and meaning.

Useful default conditions often include:

• Current or open status when the inquiry supports operational work.
• A bounded transaction date or financial period.
• A branch, company, warehouse, project, or customer scope appropriate to the audience.
• Exclusion of deleted, archived, voided, or completed records when those records do not serve the decision.
• A clear exception condition for dashboards designed for management by exception.

Parameters should reflect natural user decisions. A warehouse manager may choose warehouse and promised date. A controller may choose branch and financial period. Requiring a parameter can prevent accidental all-history requests, but it can also make an inquiry unusable for scheduled or integrated consumers. Confirm how every consumer supplies the parameter.

Avoid formulas around fields used for filtering when a direct comparison can express the same rule. A transformation applied to every candidate row may make the condition harder to evaluate efficiently. When date logic is needed, prefer bounded start and end values that preserve the intended time zone and business definition.

Test empty, default, typical, and extreme parameter values. A default that means "all" may defeat the performance objective. A default date based on the current day may be correct for one role and wrong for another. Record the default behavior in the inquiry's documentation and test plan.

Back to TOC

Control displayed rows and page size deliberately

The Interface Options settings on the Generic Inquiry form include Select Top and Records per Page. They affect how many records the user receives and sees, but they should not be used to hide an undefined population.

Acumatica's Number of Records Shown documentation states that Select Top limits the displayed result after the specified sort order is applied. It also warns that excessively large Select Top or Records per Page values can increase processing time and degrade server performance.

Use Select Top when the business question is genuinely about a ranked subset, such as the 50 oldest overdue shipments or the 25 largest open balances. Define an explicit sort that makes the subset deterministic. "Top 50" without a business order can return an unstable or meaningless selection.

Use Records per Page to support readable interaction. A larger page can reduce paging clicks but increases the amount rendered at once. Test the page size with the actual number and width of columns. A narrow inquiry with ten fields behaves differently from a result with dozens of wide calculated columns.

Acumatica 2026 R2 also exposes an option to disable record counts and totals. The form reference states that hiding the number of records or pages can make the associated inquiry load faster. This is appropriate when users do not need the count or footer totals for the decision. It is not appropriate when the count itself is the control being monitored.

Do not confuse display limits with data correctness. If a user exports data or a widget applies a separate aggregation, verify how the limit affects that consumer. Document any intentional truncation prominently enough that users do not treat a partial result as a complete population.

Back to TOC

Sort only when the result requires an order

Sorting is valuable when order conveys meaning, such as oldest first, largest variance first, or customer then document date. Sorting a large result by several fields also requires work, so each sort field should support a user task or a deterministic limit.

Acumatica's Sorting and Grouping documentation explains that the Sort Order tab defines the default order and that user-defined sorting can override it. When no explicit sort is defined, Acumatica uses a default order and shows a warning in the tab.

Review sorting with these questions:

• Does the user need the order, or is it decorative?
• Does Select Top depend on this order?
• Can the same business order be expressed with fewer fields?
• Is a text formula being sorted where a native date or numeric field would be clearer?
• Does a dashboard widget apply its own order or display only an aggregate?

Remove redundant sorts, but keep the fields required to make a limited result stable. For example, sorting by requested date alone may leave many ties. Adding a document key as a final sort can make the result repeatable without changing the primary business order.

Back to TOC

Group and aggregate without changing the metric

Grouping can reduce a detail population to one row per business dimension, but only when the selected aggregate functions match the field types and the intended measure. Acumatica supports AVG, COUNT, MAX, MIN, SUM, and STRINGAGG in the Generic Inquiry grouping configuration. The official grouping guidance notes that numeric fields default to SUM and other fields default to MAX when no aggregate is selected, while calculated fields require deliberate aggregate choices.

Start by writing the metric in plain language. "Open order value by customer" requires a definition of open order value and one output group per customer. If header amounts repeat across joined lines, summing the header amount after the join is wrong. The correct source may be a line amount, an already aggregated source inquiry, or a design that preserves one header row.

Pay close attention to these cases:

• COUNT versus distinct business entities: A row count after a detail join may count lines or allocations rather than documents.
• SUM of repeated header fields: The same order total can repeat for each child row.
• AVG after uneven duplication: Customers with more detail rows may receive unintended weight.
• MAX used as a placeholder: MAX can select one value from a group without proving that all rows share that value.
• STRINGAGG growth: Concatenating many values can create large strings that are hard to use and expensive to render.
• Null behavior: Aggregate functions may ignore null values, which can affect counts and averages.

Create reconciliation totals at both the overall and group level. If the inquiry groups by branch and customer class, validate a few known branches, then compare the grand total to an independent source. Do not accept a grand total alone because errors in different groups can offset one another.

Back to TOC

Manage formulas and calculated fields carefully

Formulas make Generic Inquiries flexible, but they can add per-row work and create subtle differences between detail and grouped results. Every formula should have an owner, a business definition, a data type, and a test set.

Use native fields when they already represent the required value. Recalculating status labels, dates, or amounts through nested expressions can make the inquiry harder to maintain and may prevent straightforward filtering or grouping. When a formula is necessary, keep it as simple as the rule allows and avoid repeating the same expression across several result fields.

Test formula behavior for:

• Null values and empty strings.
• Zero denominators.
• Currency and unit conversions.
• Time zones and date boundaries.
• Negative values and credit documents.
• Rounding before and after aggregation.
• Text values stored differently from their displayed labels.
• Grouped results where the formula references a nonaggregated field.

Acumatica's grouping documentation warns that the aggregate function must match the field type and that calculated columns need a manually selected aggregate because no single default works for every formula. A runtime error is visible; a logically wrong aggregate is more dangerous because it can look plausible.

If a formula is used only for display styling, determine whether the style is worth the cost on a large result. If it drives a condition or business decision, include it in the reconciliation evidence. Formula changes should be treated as calculation changes, not cosmetic edits.

Back to TOC

Configure grouped table views for useful analysis

A grouped table should reflect how users investigate a question. More hierarchy is not automatically better. Deep groups create extra navigation and can hide the level at which a total is defined.

Use this configuration sequence:

1. Select a base inquiry with a documented grain and validated totals.
2. Choose the first group that matches the user's primary decision, such as vendor, customer, warehouse, project, or branch.
3. Add a second group only when it supports a common drill path, such as financial period within vendor.
4. Select aggregate fields that reconcile to the base inquiry.
5. Choose a meaningful sort within each group.
6. Decide which groups open expanded or collapsed based on typical result size.
7. Show only fields needed at each level.
8. Test personal, shared, and default behavior with appropriate roles.

The grouped view should not become a substitute for a clearly scoped base inquiry. If users always filter to the current month, put that requirement in a parameter or shared filter. If executives need only a total and an exception count, a dedicated summary inquiry may be more appropriate than a detailed grouped view.

When making a shared view the default for all users, consider whether every role interprets the groups the same way. A controller may start with branch and period, while an operations manager may start with warehouse and promised date. Separate views can reuse the same inquiry when the underlying data and security are genuinely shared.

Validate the view on the expected screen width and with long labels, empty groups, negative totals, and large groups. A technically correct hierarchy can still be slow to use if users must expand many nodes or scroll across unnecessary columns.

Back to TOC

Improve dashboard performance at the consumption layer

Dashboard performance depends on the source inquiry, the number of widgets, filters, parameters, refresh intervals, and user behavior. Acumatica's Table Widgets documentation confirms that data table widgets display data collected by a Generic Inquiry. KPI widgets also select a source inquiry and aggregate a chosen field.

Start by inventorying every widget on the dashboard. Record its source inquiry, filter, parameters, displayed fields, record limit, aggregate function, and refresh setting. Two widgets that appear simple may each run a broad inquiry independently.

Match refresh intervals to business freshness

Acumatica allows widget caching and refresh intervals. The Widget Settings documentation explains that cached data is reused when it is newer than the configured interval. Selecting On Page Reload disables that reuse and updates data whenever the dashboard opens or refreshes.

Use the longest interval that still supports the decision. A weekly trend does not need a five-minute refresh. An order exception widget may need fresher data, but it should also use narrow conditions. Document the expected delay so users know whether the dashboard is current to five minutes, an hour, or a day.

Give each widget a bounded question

A scorecard should not rely on a detail inquiry that returns many unused columns. A table widget should have a reasonable record limit and should show only actionable rows. Shared filters and dashboard parameters can narrow data, but the source inquiry still needs a safe default.

Reduce simultaneous work

Remove duplicate widgets, consolidate overlapping metrics when the design remains understandable, and avoid placing every available chart on a home page. A dashboard used by hundreds of users creates a different workload from a specialist dashboard opened occasionally.

Test the dashboard as a dashboard

An inquiry tested alone may perform differently when several widgets load together. Measure the complete page, observe which widget finishes last, and test with the relevant user role. Include cache-expired and cache-valid scenarios.

For a broader view of how reporting, dashboards, and AI features fit into the current platform, see Biz-Tech's Acumatica Agentic ERP 2026 guide. Treat each feature as a consumer of governed data, not as a reason to expose a broad inquiry without controls.

Back to TOC

Treat nested Generic Inquiries as dependencies

Acumatica 2026 R2 allows a Generic Inquiry to use another Generic Inquiry as a data source. The official Generic Inquiry as Data Source documentation states that multiple simple inquiries can be combined into a more complex request and that the system prevents circular parent relationships.

This reuse can improve governance. A validated base inquiry can define a shared fact set, and several parent inquiries can apply different presentation or business rules. It can also hide complexity if the dependency chain is not documented.

For every nested source, record:

• Source inquiry title and identifier.
• Intended grain and population.
• Parameters and defaults.
• Fields exposed to the parent.
• Parent inquiries and widgets that depend on it.
• Owner and last validation date.
• Expected performance range for representative inputs.

Avoid nesting merely to avoid understanding the underlying DACs. Each level should provide a stable, reusable contract. If a child inquiry returns more fields or rows than the parent needs, consider a narrower source. If several parents independently apply the same corrective filters, the shared source definition may be incomplete.

When changing a source inquiry, test every known parent. Acumatica can warn about deleted source fields, but it cannot determine whether a retained field now has a different business meaning. Dependency testing must cover totals, sample records, filters, navigation, exports, and performance.

Back to TOC

Prevent duplicate and missing results

Performance tuning often changes relations and filters, the same settings that determine which records appear. Build correctness tests before making those changes.

Use a controlled sample that includes:

• A parent with no child record.
• A parent with one child.
• A parent with several children.
• Two document types that share a reference number pattern.
• Records across branches or companies where relevant.
• A null optional value.
• A closed or voided record near the filter boundary.
• A record exactly on the start and end date.
• A negative or credit amount.
• A record the test user cannot access.

Then validate several dimensions of the output.

Population completeness

Confirm that qualifying business entities appear and excluded entities do not. Compare known document keys, not only row counts.

Grain integrity

Confirm what one row represents after each join. If the intended grain is order line, use a composite key that identifies the line. Check for duplicate keys.

Measure reconciliation

Compare counts, quantities, and amounts with a trusted form, report, or independently validated query. State whether the source uses document currency, base currency, signed amounts, or another convention.

Security behavior

Run the inquiry as representative roles. An administrator's correct result does not prove that a restricted user sees the right population or that the inquiry avoids exposing sensitive fields.

Boundary behavior

Test dates, periods, statuses, and amounts exactly at the condition boundary. A greater-than condition and a greater-than-or-equal condition can produce different operational lists.

Do not accept a faster result until these tests pass. Performance and correctness are one release decision.

Back to TOC

Use a disciplined before and after test method

The purpose of before-and-after testing is to isolate the effect of a specific design change while preserving the business result. Use one change set at a time whenever practical.

Prepare the test

Copy the inquiry rather than overwriting the only working version. Freeze the test data or record the data snapshot time. Use the same user, role, parameters, browser path, and environment. Identify any integrations or batch processes that could distort the run.

Run the baseline

Execute the original inquiry several times for each scenario. Record usable response time, row count, distinct key count, totals, and errors. For dashboard cases, record complete dashboard load time and individual widget behavior where visible.

Apply one coherent change

Examples include correcting one relation, adding a required date parameter, removing an unused detail DAC, changing an excessive page size, disabling unused counts, or adjusting one widget refresh interval. Avoid combining many unrelated changes in the first comparison because the team will not know which change mattered.

Run the revised test

Repeat the same sequence. Compare the distribution of times, not only the fastest run. Confirm that the result has the same intended population and measures. If the change intentionally alters the population, document the new definition and validate it as a functional change.

Decide with evidence

Promote the change only when it improves the relevant user experience or resource use and passes reconciliation. A small speed difference may not justify added complexity. A major improvement that changes totals requires correction before release.

Maintain a compact evidence record containing the inquiry versions, settings changed, test cases, results, reconciliation, reviewer names, and approval. This makes later regression diagnosis much faster.

Back to TOC

Worked test case for open sales orders

This test case illustrates the method without claiming a universal performance result. Actual timing must come from the customer's build, dataset, hosting model, customizations, security role, and workload.

Business question

Which open sales orders require attention for a selected warehouse and promised-date range, with one row per sales order line?

Common slow design

The inquiry defaults to all warehouses and all dates. It joins order header, order line, allocation, shipment, customer, address, and inventory sources even though the operational list needs only order, line, customer name, warehouse, promised date, quantity, and status. Several wide description fields are returned. The result is sorted by customer name, order date, inventory description, and reference number. Records per Page is set to a very large value.

Review plan

First, confirm the required grain is one order line. Then identify which joins create multiple rows per line. Make warehouse and date-range parameters part of the normal workflow. Remove sources and columns that do not support the list, filters, navigation, or security. Keep a deterministic sort based on promised date and document keys. Select a usable page size.

Correctness controls

Use known orders with no allocation, one allocation, and multiple allocations. Confirm that the line quantity is not multiplied. Reconcile distinct order and line keys. Check orders exactly on the date boundaries and orders with partial shipment activity. Compare the population to the source sales order form using the same definition of open.

Performance evidence

Run the original and revised inquiries with the same warehouse and date range. Record repeated response times, returned rows, distinct line keys, and totals. Then test the legitimate heavy case, such as a broader date range used during backlog review. The revised inquiry is accepted only if both cases remain correct and the operational case improves meaningfully.

Expected design lesson

The likely improvement comes from scoping the population and removing unnecessary relational work, not from hiding rows after retrieval. The exact benefit cannot be promised before testing.

Back to TOC

Worked test case for grouped accounts payable analysis

This scenario uses the 2026 R2 grouped table capability for its intended analytical purpose.

Business question

Show accounts payable documents by vendor and financial period, with total and average document amount at the period level and access to individual documents for explanation.

Base inquiry requirements

The base inquiry must return the correct AP document population with a documented grain. It should include the vendor, financial period, document key, document date, status, and amount fields required by the grouped view. Conditions should define whether released, open, voided, and adjustment documents are included.

Grouped view design

Create a grouped table view with vendor as the first level and financial period as the second. Add total amount and average amount at the period level. Keep document details available beneath the group. Choose whether groups open collapsed based on the typical vendor and period count. An administrator may create a shared default view if this hierarchy suits the audience.

Performance interpretation

The grouped view may help users reach summaries without scanning a flat list. Do not state that it makes the base query faster unless the measured request changes. Compare the base table and grouped view with the same parameters, and separately measure user task completion if usability is the objective.

Correctness controls

Reconcile each vendor-period total to the base inquiry and to an accepted AP source. Check vendors with credit adjustments, multiple currencies, null optional fields, and no activity in a period. Confirm that the average uses the intended document population and that null values are handled as expected.

Expected design lesson

Grouped table views can replace cloned presentation inquiries when one validated source supports several useful hierarchies. Their strongest benefit is governed exploration, while query efficiency still depends on the base inquiry.

Back to TOC

Worked test case for an executive dashboard

Executive dashboards often reveal consumption problems because several broad queries run together.

Business question

Show the count and value of overdue shipments, the value of open orders, and a short list of the oldest exceptions, with data fresh enough for daily management.

Common slow design

Three widgets use broad detail inquiries. Each loads on every page refresh. The scorecards aggregate columns from inquiries that return many unused fields. The exception table shows hundreds of rows even though leaders act on the oldest twenty. The dashboard is set as a home page for a large user group.

Review plan

Define a narrow source for each distinct metric or a carefully governed shared source when the population is identical. Apply default exception conditions. Use only the fields required for the widget. Give the table an intentional record limit and sort. Set refresh intervals according to business freshness rather than defaulting every widget to On Page Reload.

Correctness controls

Reconcile the scorecard counts and values to the underlying exception population. Verify that the table's top records correspond to the defined order. Test with the roles that receive the dashboard. Confirm the timestamp and refresh expectation are understandable to users.

Performance evidence

Measure the dashboard after cached data has expired and again while the cache remains valid. Record full page readiness and identify any widget that lags. Test concurrent access appropriate to the user population when the environment and responsible technical team support it.

Expected design lesson

Dashboard performance is a system of query scope, widget count, caching, refresh intervals, and audience size. Improving only the visual layout does not address repeated database work.

Back to TOC

Reconcile performance changes with business totals

Reconciliation turns a technical optimization into an auditable business change. It should be designed before the test, not added after a discrepancy appears.

Use three levels of reconciliation.

Record reconciliation

Compare known business keys between original, revised, and trusted sources. Explain every missing or added key. For large populations, use counts and automated comparisons, then inspect a risk-based sample.

Aggregate reconciliation

Compare counts, quantities, and amounts overall and by meaningful groups. Useful groups include branch, warehouse, status, period, document type, customer class, and currency. Group-level comparison identifies offsetting errors that a grand total can hide.

Rule reconciliation

Verify that each condition implements the written business rule. A status label may combine several stored values. A date may represent order date, requested date, shipment date, or financial period. A balance may be in document or base currency. Document the rule beside the test evidence.

Set acceptance tolerances deliberately. Record counts and discrete document totals usually require exact agreement. Calculated currency amounts may require a defined rounding tolerance. Response times require a target range and sample size rather than one perfect run.

When totals differ, stop and classify the difference:

• The original inquiry was wrong and the revised result corrects it.
• The revised inquiry introduced a defect.
• The business definition changed.
• The test data changed between runs.
• Security or parameters differed.
• Rounding, null handling, or aggregation changed.

Do not average these causes into a vague explanation. Resolve and approve the specific difference.

Back to TOC

Deploy Generic Inquiry changes safely

Generic Inquiries can become infrastructure. They may support dashboards, exports, integration endpoints, automation, AI features, and user navigation. A change that looks local can affect several consumers.

Use a controlled deployment process:

1. Copy or export the current inquiry and dependent views before modification.
2. Record the inquiry identifier, site map location, access rights, and consumers.
3. Make and test the change in a nonproduction environment with representative data.
4. Run functional, reconciliation, performance, and security tests.
5. Review dependent dashboards, pivot tables, grouped views, OData consumers, and nested inquiries.
6. Schedule the release when rollback and observation are practical.
7. Recheck parameters, filters, roles, shared views, and default views after deployment.
8. Monitor response time, errors, totals, and user-reported differences.

Acumatica's 2026 R2 release introduces wider platform changes beyond grouped tables. If the inquiry work is part of an upgrade, coordinate it with the broader readiness plan in Biz-Tech's Acumatica 2026 R2 Upgrade Guide. Version, feature enablement, Modern UI behavior, customizations, and connected products can all affect the test scope.

Avoid editing a predefined inquiry directly when a copy is the safer governance choice. Use clear naming and descriptions so users can distinguish the supported version. Retire obsolete copies after confirming no consumer depends on them; otherwise, near-duplicate inquiries create confusion and inconsistent totals.

Back to TOC

Monitor performance after release

Performance changes as transaction volume, retention, user count, dashboards, and integrations grow. A passing implementation test is not permanent evidence.

Create a small monitoring record for important inquiries:

• Inquiry owner and business owner.
• Purpose and intended grain.
• Major consumers.
• Representative parameter scenarios.
• Expected row-count range.
• Expected response-time range.
• Key reconciliation totals.
• Last test date and Acumatica build.
• Known seasonal or period-end load.

Review the inquiry after upgrades, large data migrations, new customizations, dashboard changes, or material growth in transaction volume. Also review it when users compensate for slowness by exporting data, widening default filters, duplicating inquiries, or building spreadsheets. Those workarounds often signal that the existing design no longer supports the decision.

Track performance at the user task level. A query may become slightly faster while the user needs more manual filters or additional screens. Measure time to a usable answer, not only server response. For dashboards, include cache behavior and the number of widgets. For exports, include row volume and downstream processing.

Keep freshness honest. Update the article, inquiry documentation, and test evidence when behavior changes; do not change dates merely to imply current validation.

Back to TOC

Know when a Generic Inquiry is the wrong tool

Generic Inquiries are well suited to operational lists, governed exploration, dashboard sources, exports, navigation, and many integration or automation scenarios. They are not the best architecture for every analytical workload.

Consider another approach when the requirement involves:

• Very large historical datasets scanned repeatedly.
• Complex transformations across many fact tables.
• Heavy concurrency that competes with transactional processing.
• Long-running trend analysis with stable periodic snapshots.
• A semantic model shared across many external BI reports.
• Calculations that require extensive preprocessing.
• Regulatory reporting that needs a fixed, formally controlled output.
• A dashboard that needs data at a different refresh and storage pattern from live transactions.

Possible alternatives include a dedicated summary inquiry, a pivot table, an Acumatica report, Analytical Report Manager for the appropriate financial use, an external BI model, or a governed data warehouse. The correct choice depends on the required grain, latency, volume, auditability, and user interaction.

Do not move a workload merely because it is slow. First determine whether the inquiry is poorly scoped. Conversely, do not keep adding conditions and indexes to force an operational query tool to serve a warehouse-scale analytical problem.

Biz-Tech's overview of Acumatica Cloud ERP reporting and dashboards provides broader context for selecting reporting surfaces. Where teams need help turning business questions into governed inquiries, Biz-Tech's AI Analyst describes a review-first approach to creating and refining Generic Inquiries and related reporting assets. Product suitability, availability, licensing, and implementation scope should be confirmed for the customer's environment.

Back to TOC

Generic Inquiry performance review checklist

Use this checklist before approving a new or revised inquiry.

Business definition

• The question, audience, decision, and freshness requirement are written.
• The intended population and one-row grain are explicit.
• Counts, amounts, quantities, and dates have documented meanings.
• The business owner approves the definition.

Data design

• Every DAC and result field has a purpose.
• Relations use the complete logical keys.
• Join types preserve the intended population.
• One-to-many relationships do not duplicate measures.
• Cross joins are absent unless explicitly required and bounded.
• Nested inquiry dependencies are documented.

Filtering and limits

• Default conditions match the operational population.
• Parameters prevent accidental broad requests where appropriate.
• Empty and extreme parameter values are tested.
• Select Top has a deterministic sort and a business reason.
• Records per Page is usable and not excessive.
• Record counts and totals are enabled only when needed.

Calculation and presentation

• Aggregate functions match field types and metric definitions.
• Formulas handle nulls, zero, dates, currency, units, and rounding.
• Grouped views reflect the user's drill path.
• The grouped view is not described as a query improvement without evidence.
• Dashboard widgets use appropriate fields, filters, limits, and refresh intervals.

Testing

• The baseline and revised tests use the same environment and inputs.
• Typical and legitimate heavy scenarios are included.
• Repeated timings are recorded.
• Row counts, distinct keys, group totals, and grand totals reconcile.
• Representative user roles are tested.
• Dependent dashboards, exports, nested inquiries, and integrations are checked.

Release and monitoring

• The original design can be restored.
• Owners and dependent consumers are recorded.
• The deployment window allows observation and rollback.
• Post-release response time and totals are reviewed.
• The next review trigger is defined.

Back to TOC

Frequently Asked Questions

What is an Acumatica Generic Inquiry

An Acumatica Generic Inquiry is a configurable way to retrieve and display ERP data through data access classes without writing a conventional report for every question. Designers choose data sources, relations, conditions, parameters, grouping, sorting, and result fields on the Generic Inquiry form, SM208000. The inquiry can also serve dashboards, exports, navigation, integrations, and other governed consumers.

Why is my Acumatica Generic Inquiry slow

The most common causes are an overbroad population, unnecessary data sources, incomplete or multiplying joins, excessive formulas or sorting, very large page settings, record counts that are not needed, nested inquiry complexity, or repeated dashboard refreshes. Measure the inquiry with representative parameters and data before changing it because environmental contention can produce similar symptoms.

Do grouped table views make Generic Inquiries faster in 2026 R2

Not automatically. A grouped table organizes the results of an existing Generic Inquiry into a hierarchy with summaries and details. It can improve analysis and reduce the need for cloned presentation inquiries, but the underlying query still needs correct sources, joins, filters, calculations, and limits. Claim a speed improvement only after comparable testing.

How should I optimize joins in an Acumatica Generic Inquiry

Begin with the intended row grain, then use the complete key and foreign key fields that represent each relationship. Confirm whether each join is one-to-one or one-to-many and choose inner or outer behavior intentionally. Test parents with zero, one, and multiple children, then reconcile distinct business keys and totals to detect multiplication or missing records.

Should I use Select Top to improve Generic Inquiry performance

Use Select Top when the business question genuinely requires a ranked subset and define an explicit sort that makes the result deterministic. Do not use it to conceal an undefined or incorrect population. Verify how the limit affects exports, dashboard aggregations, and other consumers, and make any intentional truncation clear to users.

Can Records per Page be set very high

It can, but Acumatica warns that excessively large Select Top or Records per Page values can increase processing time and degrade server performance. Choose a page size that supports the user's task and test it with the actual number and width of columns. A large page is not a substitute for useful filters or parameters.

How do dashboard refresh settings affect Generic Inquiry load

Dashboard widgets can cache results for a configured interval. If On Page Reload is selected, the widget updates whenever the dashboard opens or refreshes. Frequent refreshes across many users and widgets can repeatedly execute source inquiries. Match each interval to the business freshness requirement and test the complete dashboard after cached data expires.

How do I test a Generic Inquiry optimization

Copy the inquiry, record the environment and parameters, run the original several times, and capture response time, rows, distinct keys, and totals. Apply one coherent change, repeat the same tests, and reconcile the output. Include both typical and legitimate heavy cases. Do not publish a fixed improvement percentage from another tenant's dataset.

How can I prevent duplicate totals in grouped results

Define the metric and row grain before grouping. Check whether header values repeat across joined detail rows, use the appropriate source field and aggregate, and compare distinct document keys. Reconcile totals by several business dimensions, not only at the grand-total level, because errors in separate groups can offset each other.

When should I replace a Generic Inquiry with another reporting tool

Consider another architecture when the workload repeatedly scans very large history, requires complex transformations, supports heavy analytical concurrency, or needs a governed semantic model and periodic snapshots. First correct any avoidable query-design problems. Then compare a summary inquiry, pivot, formal report, external BI model, or data warehouse against the required volume, latency, auditability, and user experience.

Back to TOC

Sources

1. Acumatica 2026 R2 Reporting Tools Guide
2. Creation of a Generic Inquiry General Information
3. Generic Inquiry Form Reference SM208000
4. Data Views General Information
5. Data Views Creating and Configuring Grouped Tables
6. Modification of Inquiry Results The Number of Records Shown
7. Data from Multiple Data Sources General Information
8. Data from Multiple Data Sources Discovery of Key Fields
9. Sorting and Grouping General Information
10. Widget Settings General Information
11. Specific Widgets Table Widgets
12. Specific Widgets KPI Widgets

Biz-Tech Services can help Acumatica teams review slow Generic Inquiries, validate joins and totals, tune dashboard consumption, and choose the appropriate reporting architecture. A reporting performance review should begin with representative data, documented business definitions, and measurable acceptance criteria rather than a promised universal speed increase.

Back to TOC

 

---

by Gary

Acumatica Modern UI Performance Troubleshooting After an Upgrade

Prepared for Biz-Tech Services | Last verified 19 October 2026

A five-layer diagnostic sequence for measurable Acumatica Modern UI troubleshooting.

When Acumatica Modern UI feels slow after an upgrade, do not begin by tuning SQL, disabling customizations, or blaming the browser. First reproduce one business task, determine whether the slowdown affects one user, one screen, or the whole site, and compare browser timing with Acumatica Request Profiler data. That sequence separates client and network delay from application-server, Generic Inquiry, customization, and database causes.

The key is to diagnose a transaction rather than a feeling. “The system is slow” cannot be tested. “Opening Sales Orders as the warehouse supervisor takes 11 seconds on the first load and 8 seconds on a warm repeat, while other users complete it in 3 seconds” gives the team a screen, role, browser, data state, timing, and comparison point.

This guide provides a repeatable diagnostic sequence for Acumatica 2026 R1 and 2026 R2 environments. Test every conclusion against the exact build, database, customizations, roles, and data volumes used by your organization. Community reports can help identify questions to investigate, but they do not establish the cause in your tenant.

What counts as an Acumatica Modern UI performance problem?

An Acumatica Modern UI performance problem is a repeatable delay in a defined user task, request, inquiry, or process compared with an accepted baseline. The delay may come from the browser, network, application server, database, Generic Inquiry design, customization code, automation, or the number of interactions required to finish the task.

That last distinction matters. A page can return quickly while users still need more clicks or pointer movement than before. Conversely, a workflow can feel familiar while a server request, SQL statement, or integration call is taking too long. Measure both technical response time and task completion time when the complaint concerns productivity.

Acumatica's official troubleshooting guide begins with the same scope distinction: either the whole site is slow or a particular process is slow. It then moves through basic causes, application-versus-database time, server configuration, database checks, additional evidence collection, and support escalation. [1]

Start with four classification questions

Before collecting a large trace, answer four questions:

1. What exact action is slow? Name the screen, action, record, filters, and expected result.

2. How wide is the impact? One user, one role, one location, one browser, one screen, or the whole site?

3. When does it happen? First load only, every repetition, certain data volumes, a scheduled period, or under concurrency?

4. What changed? Acumatica build, browser, customization package, Generic Inquiry, database, infrastructure, integration, role, or data volume?

Run the same transaction at least three times. Record the first result separately because cold browser assets, application caches, database caches, or freshly started services can make the first run different from warm repeats. Use the same record and filters where possible, and do not compare an administrator's broad access with a production role unless role differences are part of the test.

The five-layer diagnostic sequence

1. Reproduce the user task and capture browser evidence

Open the browser's developer tools before reproducing the issue. On the Network panel, preserve the log, capture the slow action, and note the request with the longest elapsed time. Record whether the wait is primarily before the request starts, during connection and transfer, or while waiting for the server response. Acumatica's Modern UI uses web technologies and request-based communication that browser development tools can inspect. [2]

Repeat in another supported browser or a clean browser profile. If the problem occurs only in one profile, examine extensions, cached assets, local storage, security software, and browser policy. If it occurs only from one location, compare latency, VPN path, proxy, DNS, packet loss, and bandwidth. Acumatica's official first-step guidance explicitly recommends comparing browsers and physical locations before moving deeper into the stack. [1]

Do not stop when clearing cache appears to help once. Retest the same task after the browser and server are warm. A cache reset can remove stale assets, but it can also create a slower first load and hide an intermittent problem.

2. Compare browser time with Acumatica Request Profiler

Use Request Profiler (SM205070) to determine whether Acumatica spent the time on the server. For a particular process, open Settings > Profiler, start logging, reproduce only the target transaction, stop logging, and export the profile. The exported ZIP can include URL requests, SQL activity, exceptions, warnings, errors, and stack details needed for analysis or support. [3]

Compare three values:

Measurement	What it tells you	Likely next owner
Browser elapsed time is high, profiler server time is low	Delay is outside most Acumatica server processing	Browser, endpoint security, proxy, VPN, or network owner
Profiler server time is high, SQL time is low	Application logic, customization, external call, serialization, or server capacity may dominate	Acumatica administrator or developer
SQL time is a large share of server time	Query design, blocking, indexing, statistics, plan choice, or database capacity needs review	SQL specialist with Acumatica context
Both timings are reasonable but the task is slow	Interaction design, navigation, or repeated manual steps may be the issue	Process owner and Modern UI specialist

Request Profiler has default thresholds for automatic monitoring, including 20 seconds for certain screen, Generic Inquiry, and report requests and 60 seconds for other requests. Those values are logging defaults, not promises of acceptable performance. Your baseline must reflect the business task and environment. [3]

3. Isolate Generic Inquiry and customization cost

If the slow screen, selector, dashboard, AI data source, or export depends on a Generic Inquiry, reproduce it with the exact role, filters, parameters, sorting, and row volume. A GI that is quick for a narrow test may become expensive when a condition is removed, a calculated field is added, a join multiplies rows, or a user exports the complete result.

Capture the inquiry name, parameters, returned row count, total browser time, Request Profiler server time, and SQL time. Then test one controlled change at a time. Narrow the date range, remove a nonessential calculated field, simplify sorting, or replace a broad join only in a sandbox. Keep the result set logically equivalent before calling the change an optimization.

For a suspected customization, compare the same action before and after unpublishing the specific project in a safe environment. Acumatica's troubleshooting guidance recommends profiling the action without the suspected project, publishing it again, repeating the same action, and comparing results. [1] A clean-system test does not prove that every customization is faulty; it identifies whether the measured cost changes when a defined package is present.

Check more than custom business logic. Modern UI customization problems can involve client-side code, generated files, build errors, stale assets, screen definitions, or API calls. Review browser console errors and the customization build output alongside server traces. If a customization calls an external service, time that dependency separately so a slow remote response is not mislabeled as database latency.

4. Investigate database and environment causes

When SQL consumes a material part of the slow request, capture the exact query context before changing indexes. Review blocking, long-running statements, execution plans, resource pressure, storage latency, database growth, statistics, and maintenance history. Acumatica's official sequence includes SQL Server configuration and reports or the corresponding MySQL checks after application-server analysis. [1]

Also inspect the environment around the transaction:

• running processes and automation schedules;
• System Monitor activity and unusually long jobs;
• application-pool memory and recent recycling;
• CPU, memory, disk latency, and database-server pressure;
• antivirus or endpoint scanning on application paths;
• license or concurrency conditions where relevant;
• integrations or imports running during the same period.

Correlate timestamps. A request that slows at 10:00 every morning may coincide with automation, backups, reporting, virus scanning, or an integration batch. Evidence from different clocks is hard to compare, so record the time zone and ensure application, database, monitoring, and workstation clocks are aligned.

5. Decide whether to optimize, patch, or escalate

Optimize when the evidence identifies a repeatable design cost that your team owns: an overbroad GI, an inefficient customization, unnecessary external calls, a poorly scheduled process, or an environment bottleneck. Make one change, rerun the same test, and record both the performance difference and functional result.

Patch when the behavior matches a documented defect for the exact Acumatica build and the release guidance identifies a corrected build. Validate the patch in a production-like sandbox with the same workflow, role, data, and customizations. “A newer build exists” is not enough evidence by itself.

Escalate when the problem is reproducible but the available evidence does not isolate an owned component, or when the trace points to platform behavior that requires Acumatica Support. Submit a focused case with the build, deployment model, timestamps, screen ID, steps, role, browser, profile export, logs, data scope, business impact, recent changes, comparisons, and tests already completed. This follows Acumatica's documented sequence: collect Request Profiler and log evidence before opening the support case. [1] [3]

The first five measurements to capture

If time is limited, collect these five measurements before changing anything:

1. Business-task duration: start-to-finish time for one named task, including the record and filters used.

2. Browser request duration: the slowest relevant request from the Network panel, plus a HAR file when permitted by security policy.

3. Request Profiler server and SQL time: captured during the same reproduction window.

4. Scope comparison: same task from another supported browser, user or role, and location.

5. Environment context: build number, customization packages, dataset size or row count, concurrent jobs, and timestamp.

Together, these measurements prevent three common mistakes: treating a local browser issue as a database problem, tuning SQL for time spent in application or external code, and escalating without a reproducible transaction.

Acumatica performance evidence worksheet

Use one row per controlled test. Attach the exported files separately rather than pasting sensitive data into the worksheet.

Field	What to record
Business task	Screen ID, action, record, filters, expected result
Impact	Users, roles, locations, and frequency affected
Environment	Acumatica version and build, deployment, app and database topology
Client	Browser/version, device, extensions, VPN/proxy, location
Change history	Upgrade, patch, customization, GI, browser, infrastructure, or data change
Test controls	Same data, same role, cold or warm run, repetition count
User timing	Total task-completion time for each run
Browser timing	Slow request URL or operation, status, waiting and transfer time
Profiler timing	Total server time, SQL time, memory, exceptions, relevant trace rows
Database evidence	Blocking, long query, plan, resource or storage observation
Comparison	Baseline environment, alternate browser/location, customization on/off
Result	Confirmed layer, rejected hypotheses, next owner and next test
Attachments	HAR, profiler ZIP, logs, screenshots, query plan, monitoring export

Sanitize customer names, personal data, credentials, tokens, and business-sensitive values before sharing evidence outside the authorized team. First-chance exception logging and other verbose diagnostics should be enabled only for the short period needed because the output can grow quickly. [1]

Build a reliable performance baseline before troubleshooting

A performance baseline is a documented range for a repeatable business task under known conditions. It is more useful than a single target such as “every screen must load in two seconds” because different Acumatica actions perform different amounts of work. Opening a maintained customer record, calculating a large inquiry, releasing a batch, and exporting thousands of rows should not be evaluated as if they were the same transaction.

Begin with ten to twenty tasks that represent the work people depend on most. Include the actions that affect cash, fulfillment, production, customer service, purchasing, project billing, and financial close. For each task, record the screen ID, role, data volume, record state, filter set, browser, location, build, and number of concurrent users or processes. A useful baseline is specific enough that another analyst can reproduce it without asking what the original tester meant.

Measure the full task from the user's perspective and the important requests inside it. Total task time shows whether the employee can complete the work efficiently. Browser and Request Profiler timings show which technical layer contributed to the wait. Retain both because an improvement in one request may not reduce the number of steps, and a shorter task may hide an expensive background call.

Use a small series rather than one run. A practical starting point is one cold run followed by at least three warm runs. Record every value instead of keeping only the fastest result. The median warm time describes the typical experience better than a best-case number, while the slowest valid run helps reveal intermittent blocking, network variation, or competing jobs. Do not combine failed tests, different records, or changed filters into the same comparison.

Define the acceptable range with the process owner. The threshold should reflect the business consequence of the delay, the normal data volume, the frequency of the action, and the technical work involved. A two-second increase on an action performed hundreds of times per day can matter more than a longer delay on a monthly report. The baseline therefore connects technology measurements to operational cost.

Baseline element	Minimum definition	Why it matters
Task identity	Screen ID, action, record state, filters, expected result	Prevents unlike transactions from being compared
User context	Role, branch, company, locale, and relevant preferences	Security and configuration can change the work performed
Data context	Row count, date range, document size, and related history	Performance often changes with scale
Client context	Browser/version, device, location, VPN or proxy path	Separates client and network effects
Server context	Build, topology, packages, integrations, and scheduled activity	Makes the test environment reproducible
Timing method	Cold or warm run, start and stop points, repetition count	Keeps measurements consistent
Acceptance rule	Expected range, warning level, owner, and review date	Converts evidence into a decision

Acumatica performance baseline: A useful baseline is a versioned record of how long a defined business task and its principal requests take under repeatable conditions. It must identify the build, role, data, client, environment, timing method, and acceptable range. Without those controls, a before-and-after comparison can describe different work rather than a real performance change.

Diagnose by scope before diagnosing by technology

Scope is the fastest way to reduce the number of plausible causes. Ask how many users, screens, processes, locations, and time periods are affected. The answers do not prove a cause, but they determine the next comparison that will produce the most information.

One user is affected

When one user is affected and peers with the same role can repeat the task normally, compare the endpoint first. Check the browser version and profile, extensions, cached assets, local storage, endpoint protection, device resource pressure, display or accessibility tools, VPN state, and network route. Then compare the user's role, preferences, branch, company, and saved filters with a working peer.

Do not assume that “one user” means “one computer.” Have the user sign in on a known-good device when policy permits, and have a comparison user test the affected device. This two-way test separates user configuration from endpoint configuration more cleanly than reinstalling software or changing several settings at once.

One screen or action is affected

When the rest of the site performs normally, focus on the dependencies of that transaction. Identify its Generic Inquiries, selectors, dashboards, reports, customization code, external calls, attachments, automation steps, and database queries. Capture Request Profiler data for only that action so unrelated requests do not obscure the trace.

Use a neighboring transaction as a control. If Sales Orders is slow, compare another screen that uses the same customer and inventory data but not the same customization. If an inquiry is slow, compare a narrower filter and a known-simple inquiry under the same role. The control helps identify whether the issue follows the data, the screen design, or the environment.

One location is affected

When users in one office, warehouse, or remote network are affected, compare connection setup and request timing. Record round-trip latency, VPN or proxy use, packet loss, DNS behavior, and whether large static assets or API responses are delayed. A browser HAR file can show whether time accumulates before the server responds or during transfer.

Avoid treating a successful ping as proof that the application path is healthy. Acumatica traffic may pass through gateways, inspection services, load balancers, or identity components that a simple network test does not exercise. Compare the actual browser transaction from affected and unaffected locations.

The whole site is affected

When many users and unrelated screens slow at the same time, widen the evidence window. Review application-server resources, application-pool behavior, database pressure, blocking, storage latency, running processes, scheduled automation, integrations, backups, scanning, and license or concurrency conditions where applicable. Acumatica's official troubleshooting sequence specifically separates overall-site performance from a slow individual process because the likely evidence and corrective actions differ. [1]

The problem appears only at certain times

Time-bound issues often correlate with other workloads. Map the slowdown against automation schedules, imports, exports, backups, maintenance, reporting, integration bursts, end-of-period activity, and user concurrency. Use a shared time zone and synchronized clocks. The strongest evidence is a repeated correlation between the slow transaction and a measured competing workload, followed by a controlled schedule or resource change that removes the effect.

Observed scope	Highest-value first comparison	Common evidence to collect
One user	Same user on another device; another user on the affected device	Browser profile, role, preferences, endpoint and route
One screen	Same screen with controlled data; neighboring screen as a control	Network request, profiler trace, GI, customization, SQL
One location	Same task from another location	HAR, latency, proxy/VPN path, transfer timing
Whole site	Unrelated screens and users during the same period	Server resources, jobs, blocking, storage, concurrency
Certain times	Same task inside and outside the affected window	Schedules, monitoring timeline, process history, correlations

Read browser evidence without misdiagnosing the server

The browser Network panel is most valuable when it is used to answer a precise question: where did the elapsed time accumulate for the request associated with the slow action? Preserve the log, reproduce one transaction, and identify the request or sequence that aligns with the user's wait. Record the request name or URL pattern, method, status, start time, duration, response size, and timing phases.

A long wait before a request is sent can indicate browser queuing, client-side work, connection limits, or another blocking resource. A long connection phase can point toward DNS, proxy, TLS, VPN, routing, or network instability. A long wait for the first response byte is consistent with time spent beyond the browser, but it does not by itself distinguish application code, SQL, an external dependency, or server capacity. A long content download can reflect response size or transfer conditions.

Use the browser Console as supporting evidence. Repeated exceptions, failed resource loads, blocked requests, or customization errors may explain a stalled interface even when the backend request is reasonable. Capture the exact message, timestamp, source, and action that produced it. A console warning unrelated to the tested transaction is not automatically the cause.

HAR files can contain URLs, parameters, record identifiers, headers, cookies, or other sensitive information. Follow the organization's data-handling policy before exporting or sharing them. Remove credentials and sensitive values, retain an unmodified copy only in an approved location when required, and tell the recipient what was sanitized.

Compare like with like. Use the same browser cache condition, record, role, and request sequence for the affected and control tests. If one test is the first visit after clearing cache and the other is a warm repeat, the comparison does not isolate the variable you intended to test.

Browser time versus Acumatica server time: Browser elapsed time includes work outside the Acumatica server, while Request Profiler server time measures processing recorded by Acumatica. When browser time is much higher than profiler time, investigate the client and delivery path. When profiler time explains most of the browser wait, inspect application, customization, external dependency, and SQL evidence inside the server trace.

Use Request Profiler as a controlled experiment

Request Profiler is not merely a place to collect a large log. It is a tool for connecting a user action to server time, SQL time, memory, exceptions, and trace details. The clearest profile contains the smallest practical set of activity that reproduces the issue.

Before starting logging, prepare the target screen and the exact record or filter. Note the local time and the tester. Start the profiler, perform the action once, stop logging promptly, and export the result. Avoid navigating through unrelated screens during the capture. If the slow behavior requires a sequence, document every step so the recipient can match the profile entries to the user's actions.

Interpret totals in context. Server time that is high with little SQL time directs attention to application logic, customization code, serialization, external calls, or resource pressure. SQL time that closely tracks server time directs attention to the generated query, blocking, plan, data distribution, and database resources. Exceptions and warnings may reveal a repeated fallback or retry, but they still need to be matched to the transaction.

Memory figures can help compare two versions of the same action. A large difference does not establish a leak on its own; it identifies a transaction that deserves a longer observation or code review. Likewise, one expensive request does not explain a whole-site complaint unless its timing and concurrency align with the broader impact.

Acumatica documents automatic monitoring thresholds in Request Profiler, including defaults for certain screen, Generic Inquiry, report, and other requests. Use those thresholds to understand what the profiler records automatically, not as universal service-level targets. [3] A frequently repeated four-second action may be operationally significant even if it does not cross an automatic logging threshold.

Run A/B comparisons with only one intentional difference:

1. Capture the task on the current build and package set.

2. Change one variable in a sandbox, such as the suspected customization, GI revision, browser path, or schedule.

3. Repeat the same record, role, filters, cache condition, and repetition method.

4. Compare user time, browser time, server time, SQL time, memory, result correctness, and any exceptions.

5. Restore or retain the change according to the test plan, then document the conclusion and next owner.

If several variables change together, the test may show improvement without explaining it. That makes the result difficult to reproduce and risky to promote into production.

Troubleshoot Generic Inquiry performance methodically

Generic Inquiries are frequently reused across screens, dashboards, exports, integrations, AI tools, and operational reporting. A design that appears in one place can therefore influence several user experiences. Troubleshooting should protect the business meaning of the inquiry while reducing unnecessary work.

Start by documenting what the GI is supposed to return. Identify the business grain: one row per sales order, line, shipment, customer, inventory item, or another defined entity. If joins create more rows than the business grain allows, the inquiry may process and return duplicate combinations even when users see a familiar result after grouping.

Review joins and conditions together. A correct relationship with an incomplete join condition can multiply rows. A filter applied after a broad join can make the database assemble a much larger intermediate result than the final grid suggests. Calculated fields, subqueries, aggregation, grouping, and sorting can add work, especially when the result covers a long period or many branches.

Test the GI with the production role rather than only an administrator. Security scope and accessible companies, branches, customers, or records can change both the result and the generated work. Record parameters and saved filters because two users can appear to open the same inquiry while requesting different datasets.

Pay attention to selectors and dashboards. A selector may execute while a user enters data, so a moderate delay repeated many times becomes disruptive. A dashboard can issue several inquiries at once, making its total load a concurrency problem rather than a single-query problem. Isolate each component before optimizing the combined page.

For exports, distinguish grid display from full dataset retrieval. The visible page may load a limited result while an export requests far more rows, columns, formatting, or calculated values. Record both the displayed row count and the exported row count.

Use the following sequence in a sandbox:

1. Confirm the required business grain and columns.

2. Reproduce with the exact role, parameters, filters, sorting, and data range.

3. Record browser, server, and SQL time plus returned row count.

4. Check joins for unintended multiplication and filters for unnecessary breadth.

5. Remove one nonessential column, calculation, sort, group, or join at a time.

6. Compare timing and validate totals, distinct keys, and sample records.

7. Test every consumer that depends on the inquiry before publishing the revision.

Slow Generic Inquiry diagnosis: A slow GI should be evaluated by business grain, joins, conditions, calculations, sorting, security scope, parameters, and returned volume. The safe optimization is the smallest design change that reduces measured work while preserving record counts, totals, keys, navigation, security, and downstream consumers.

Isolate Modern UI customization and integration effects

Customization troubleshooting should identify a package, component, or call path rather than classify all custom code as the problem. Begin with the dependency map for the slow task: screen extension, graph extension, event handler, client-side code, API call, external service, custom inquiry, automation, and any overridden behavior.

Check publication and build evidence after the upgrade. A customization can publish successfully while still performing unnecessary work at runtime. Conversely, a client-side build error, stale generated asset, or browser exception can impair the interface before the server transaction begins. Review both the customization build output and the browser evidence.

When safe, compare the same task with the suspected project unpublished and republished in a sandbox. Keep every other relevant condition constant. Acumatica's performance troubleshooting guidance describes this comparison as a way to identify customization involvement. [1] The result should be framed precisely: “server time decreased when package X was absent” is evidence; “all customization is slow” is not.

If several projects depend on one another, test a supported package set. Do not create an artificial environment that cannot execute the transaction correctly. Record dependencies, publication order, build output, and functional differences. A faster test that skips required business logic is not an acceptable optimization.

Time external dependencies independently. A customization may call a tax provider, carrier, commerce platform, document service, or internal API. Capture the start, finish, outcome, timeout, and retry behavior of that call. If Acumatica waits for a remote response, database tuning will not remove the delay. Consider whether the interaction must be synchronous, but treat architecture changes as a separate design decision with business and recovery implications.

Review repeated work. Code that queries or recalculates once per line, field event, or grid refresh can scale poorly as document size grows. Compare a small and large document while holding other variables constant. A sharply increasing curve is more informative than a single slow example.

Validate behavior after every performance change. Confirm field defaults, totals, taxes, discounts, inventory allocation, approvals, releases, notes, attachments, integrations, and audit expectations that the customization affects. Performance is one acceptance dimension; the transaction must remain correct and supportable.

Investigate SQL without jumping directly to indexes

SQL evidence should begin with the query and its operating context. Identify the Acumatica action, profiler entry, parameters, duration, reads where available, wait or blocking condition, execution plan, data scale, and competing activity. This prevents a database change from being based on an isolated statement copied without the application conditions that produced it.

Blocking and resource pressure can make a normally efficient query appear slow. Check whether the statement was waiting on another transaction, storage, memory, CPU, or a concurrent maintenance operation. Correlate the database timeline with the Acumatica and browser timestamps. A plan captured after the event may not reflect the plan or parameter values used during the slow execution.

Review data distribution and statistics. An upgrade can coincide with data growth, changed filters, new workflows, or maintenance differences even when the underlying query text is familiar. A plan that works for a narrow parameter may perform poorly for a broad one. Record the actual business parameters before testing an alternative.

Do not add an index solely because a tool suggests it. Evaluate write cost, storage, overlap with existing indexes, maintenance, upgrade support, and whether the query comes from a customization or a standard process. A targeted GI or code change may reduce more work with less long-term cost. Database changes should follow the organization's Acumatica support and change-control practices.

For overall-site issues, examine server configuration and health in the order described by the official guide. Acumatica's troubleshooting sequence includes the distinction between application-server and database-server time, followed by server and database checks and then additional evidence collection. [1] This order reduces the risk of tuning the database when most of the elapsed time occurs elsewhere.

Retest with the same workload after any change. Compare not only duration but also reads, CPU, blocking, result counts, and the effect on concurrent transactions. An improvement for one query that degrades order entry, imports, or release processing is not a successful system-level fix.

Account for post-upgrade conditions that distort results

The period immediately after an upgrade can produce measurements that do not represent steady-state operation. Application services may have restarted, caches may be cold, browser assets may have changed, database plans may be refreshed, and scheduled jobs may be catching up. Users may also be learning new navigation, which affects task time independently of server performance.

Separate stabilization observations into technical response and human execution. Measure the request sequence, and also watch a trained user complete the entire task. If requests are fast but the task takes longer, investigate layout, focus order, keyboard use, saved views, filters, and the number of interactions. If the same steps remain but requests are slower, continue with browser, profiler, customization, and database evidence.

Verify the exact build and package set. A statement about “2026 R1” or “2026 R2” is too broad for support or regression work because maintenance builds and customization revisions can differ. Record the complete Acumatica build, browser version, package versions, deployment topology, database version, and date of the test.

Warm the environment in a controlled way before accepting a baseline. Run the selected tasks once, then measure the defined warm series. Keep cold-start results as a separate operational measure if restarts or scale-out events matter to the business. Do not discard cold behavior; label it correctly.

Confirm background recovery. Integrations, automation schedules, search indexes, reporting extracts, or other processes may resume after an upgrade and compete for resources. Record queue depth and completion state. A slowdown caused by temporary backlog requires a different response from a repeatable screen defect.

Compare with the pre-upgrade environment only when the data and test method are comparable. A refreshed sandbox with a larger database, different integrations, fewer server resources, or different user concurrency cannot provide a clean version comparison. Document unavoidable differences and avoid claiming that the release caused the full measured gap.

The Acumatica 2026 R2 Upgrade Guide provides the broader readiness and stabilization framework. The Modern UI Migration Readiness guide helps teams identify complete role-based tasks so the performance test covers more than opening a screen.

Prepare an escalation package that support can use immediately

A strong escalation package allows another technical team to reproduce the issue, understand its business impact, and inspect the same evidence without beginning with basic discovery. Keep it focused enough to review and complete enough to act on.

Start with a one-paragraph summary. Name the environment, full build, affected task, scope, expected behavior, observed behavior, and business consequence. Include the first observed date and whether the issue began after a known change. Avoid conclusions that the evidence has not established.

Provide exact reproduction steps. State the screen ID, role, record or sanitized equivalent, filter values, buttons or actions, expected result, observed time, repetition count, and frequency. Explain whether the first run differs from warm repeats. If production data cannot be shared, describe the minimum data characteristics needed to reproduce the workload.

Attach a timeline using one time zone. Include the browser capture time, profiler session, application log interval, database observation, and any concurrent job. This lets support align events that were recorded by different systems.

Summarize comparisons already completed:

• affected and unaffected user;
• affected and unaffected location;
• supported browsers or clean profile;
• cold and warm run;
• customization present and absent in a sandbox;
• narrow and broad data range;
• normal and affected time window;
• current and comparison build when valid.

List the result of each comparison, including tests that rejected a hypothesis. This prevents repeated work and shows which variables are still open. Attach the Request Profiler export, sanitized HAR when allowed, relevant logs, screenshots, build and package inventory, monitoring graphs, and database evidence. Do not attach an entire unrestricted log archive when a focused interval will answer the question.

Close with the assistance requested. Ask whether support should confirm a known defect, interpret a trace, recommend a corrected build, review platform behavior, or advise on the next diagnostic step. A precise request is easier to route than “please fix performance.”

Minimum Acumatica support evidence: Provide the full build, deployment model, business impact, screen ID, exact steps, role, record and filters, timestamps, browser timing, Request Profiler export, relevant logs, package inventory, comparisons performed, and a clear request. Sanitize sensitive data while preserving the technical relationships needed for reproduction.

How to prevent performance regressions after the fix

Turn the confirmed transaction into a regression test. Store the screen, role, filters, representative record, row count, cold or warm condition, expected result, and acceptable range. Run it after Acumatica builds, browser changes, GI revisions, customization releases, and infrastructure work.

Include high-volume and exception paths, not only a blank screen or a small demo record. For the broader upgrade process, the Acumatica 2026 R2 Upgrade Guide explains how to build performance checks into sandbox validation and stabilization. If your organization is still moving custom screens and workflows, use the Modern UI Migration Readiness guide to inventory the role-based tasks that need coverage.

The goal is a small, trusted baseline rather than a single universal threshold. A sales-order screen, a 200,000-row inquiry export, and a batch release have different purposes. Each needs a business owner, representative data, and an agreed measurement.

Frequently asked questions

Why is Acumatica Modern UI slow only on the first load?

The first load may include browser assets, application initialization, and cold caches that later runs reuse. Record the cold result separately, then repeat the same action on a warm session. If only the first load is slow, inspect static-asset delivery, cache behavior, browser policy, and application startup rather than averaging the first and later runs together.

How do I tell whether Acumatica or the network is slow?

Compare the browser's elapsed request time with Request Profiler server time for the same action. A long browser request with low server time points toward the client, network, proxy, or endpoint path. High server time means the delay is within application processing, SQL, customization code, an external dependency, or server capacity.

Can a Generic Inquiry make Modern UI feel slow?

Yes. Joins, calculated fields, filters, sorting, security scope, returned row volume, and exports can increase the work behind a Generic Inquiry. Test the exact role and parameters, capture row count and profiler timings, then change one element in a sandbox while verifying that the business result remains correct.

Should I clear the browser cache after an Acumatica upgrade?

Clearing stale browser assets can be a valid controlled test, especially after UI or customization changes, but it is not a complete diagnosis. Record the result, distinguish the next cold load from warm repeats, and confirm whether the improvement persists. If the issue returns, capture browser and server evidence instead of repeating cache clearing as the only remedy.

When should I open an Acumatica Support case?

Open a case when you can reproduce the issue but cannot isolate an owned component, when evidence points to platform behavior, or when a documented defect may apply. Include the exact build, steps, timestamps, screen ID, role, browser, profiler export, relevant logs, comparisons, and business impact so support can begin with evidence rather than request basic reproduction details.

Get a focused Acumatica performance diagnostic

Biz-Tech Services can help reproduce a slow Acumatica transaction, separate browser, network, application, customization, Generic Inquiry, and database causes, and prepare an evidence package for remediation or support. Explore Biz-Tech Services Acumatica consulting and support or contact the team to request a performance diagnostic for your exact build and workflow.

Sources

1. Acumatica 2026 R2 System Administration Guide: Troubleshooting Performance

2. Acumatica: A Modern User Interface for a New Technology Era, Part I

3. Acumatica 2026 R2 System Administration Guide: Request Profiler

4. Acumatica 2025 R1 Modern UI overview

5. Acumatica Community: How is 26R1 Modern UI performing for you? (directional user reports; verify in your own environment)

---

by Gary

Acumatica AI Agents and Agent Actions: A Governed Automation Playbook

Acumatica AI agents can become controlled steps inside an ERP process: a user, business event, import scenario, schedule, or workflow invokes an agent action; the agent reads the current record and approved supporting data; it writes a bounded result; and the surrounding process decides what happens next. The practical opportunity in Acumatica 2026 R2 is therefore not unrestricted autonomous ERP. It is governed automation in which the target record, available tools, editable fields, trigger, review point, exception path, and audit evidence are designed before activation.

That distinction matters because an agent can change business records. A useful implementation does more than write a persuasive instruction. It limits the data the model can retrieve, exposes only the tools required for the task, constrains outputs to values that downstream rules can evaluate, tests both normal and adverse cases, and assigns a human owner. Acumatica provides relevant controls through the Agents form, endpoint-backed tools, published Generic Inquiries, field masking, result previews, processing logs, token statistics, AI Automation History, business events, workflows, and import scenarios. Those controls still require process design and operational discipline.

This playbook explains how finance, operations, IT, and process owners can select a suitable use case, design the agent boundary, protect sensitive data, build approval and exception paths, test changes, monitor cost and behavior, and scale only after evidence supports the decision. It focuses specifically on Acumatica AI Automation agents and agent actions. For the broader 2026 R2 program, see the Biz-Tech Acumatica 2026 R2 Upgrade Guide.

Executive Summary for Business and Technology Leaders

An Acumatica AI agent is most valuable when it applies judgment to a narrow record-level task that ordinary rules cannot express cleanly. Examples include classifying an incoming record, drafting a bounded description, comparing a current transaction with approved reference data, or assigning one of several defined review outcomes. Acumatica documentation describes agents that can retrieve the current record, update editable fields and detail lines, and retrieve supporting information through published Generic Inquiries. Once activated, an agent action can be invoked manually or by a configured business event, import scenario, or workflow.

The control model should begin outside the model. The process must specify which record exists before the agent runs, what data the agent may receive, what fields it may update, which output values are valid, what event or transition may follow, and who reviews exceptions. Acumatica notes that an agent works with the current record on its target form and cannot create a new record on that form. It also cannot invoke another target-form action from inside the agent. Record creation, releases, notifications, status transitions, and other actions should remain separate, visible process steps.

The safest first production use case usually has five characteristics:

• A clear owner can explain the business decision in plain language.
• The required data is available on one target form or through a small number of governed Generic Inquiries.
• The permitted output can be limited to a small set of fields or values.
• A person can verify correctness without recreating the entire analysis.
• An incorrect result can be contained, corrected, and traced without financial posting or irreversible downstream effects.

The rollout decision should be evidence based. A pilot should show that the agent selects the right scope, uses the intended tools, produces acceptable changes, routes uncertainty correctly, stays within a tolerable token and processing budget, and fails safely when data is missing or instructions conflict. If those conditions are not demonstrated, the next action is not broader deployment. It is a narrower boundary, better source data, clearer instructions, or a conventional deterministic rule.

Back to Table of Contents

What an Acumatica AI Agent and Agent Action Actually Do

In Acumatica 2026 R2, the Agents form ML202000 is used to configure and test AI Automation agents. Selecting a target data-entry form gives the agent a current-record context. Acumatica adds standard tools that retrieve the current record and apply updates to editable fields or detail lines. A configured endpoint defines which entity and fields those tools expose. Supporting data can be added through Generic Inquiry tools, with one published inquiry per tool.

After testing, activating most agents adds a generated command to the target form. A user can invoke that command from the More menu or add it as a favorite. The action can also participate in a process started by a record change, schedule, user action, import, business event, or automation workflow. Acumatica registers an internal action name that begins with LLMAction_ followed by the agent ID; workflow and import-scenario configurations use that name.

The agent is not the whole process. It is one step that retrieves information, applies the instructions, and returns a bounded result. A subsequent business event or workflow condition can evaluate the value written by the agent and decide whether to notify a reviewer, assign a task, run another step, or move the record. This separation is useful because it leaves deterministic routing and approvals in Acumatica configuration rather than asking the model to control every consequence.

The boundary also prevents common overstatements. An agent does not receive unrestricted database access merely because it operates inside the ERP. It receives what its tools, endpoints, Generic Inquiries, filters, and current-record context expose. It cannot update fields that are read-only through the configured endpoint, and it cannot update a detail line if the line cannot be edited manually on the target form. If a task requires a dialog, another form, or a target-form action, that task belongs in a separate workflow step or customization.

Back to Table of Contents

How AI Automation Differs from AI Assistant and Biz Tech AI Analyst

Acumatica AI Automation, Acumatica AI Assistant, and Biz-Tech AI Analyst solve different problems. Treating them as interchangeable leads to poor architecture and confusing expectations.

Acumatica AI Automation agents operate in a configured record context. They can retrieve current-record data, call approved supporting tools, and update fields that the configured endpoint permits. Their natural role is bounded execution within a business process. The governance question is which actions, data, fields, triggers, and outcomes are permitted.

Acumatica AI Assistant is oriented toward conversational analysis. The Assistant works with administrator-exposed Generic Inquiries so users can ask questions, examine source records, and create analytical outputs such as tables, charts, pivots, or dashboard widgets. It is suited to finding and explaining information, while AI Automation agents are designed to participate in defined process steps. Organizations planning both should maintain separate ownership, access reviews, use-case inventories, and acceptance tests. The Biz-Tech guide to Acumatica AI Assistant governance covers that analytical use case in more detail.

Biz-Tech AI Analyst is a separate Biz-Tech product for creating and refining Acumatica reports, Generic Inquiries, and Import Scenarios through a proposal-and-approval process. It can help turn business requirements into governed designs, including import mappings, but it does not replace Acumatica AI Automation or remove the need to govern an agent action. AI Analyst presents the proposed data sources, fields, filters, grouping, mapping, and limitations before building or changing a design. For imports, the user's team retains control of Prepare and Import.

These products can complement one another. A team might use Biz-Tech AI Analyst to prepare a narrowly scoped Generic Inquiry or Import Scenario, use Acumatica AI Automation to apply judgment to each current record, and use Acumatica AI Assistant to analyze approved results. The architecture is sound only when each capability retains its own access boundary, review process, and operational owner.

Back to Table of Contents

Choose a Process That Benefits from Model Judgment

The first design decision is whether the task needs an LLM. Many ERP actions are better implemented with formulas, workflows, business events, approval maps, import mappings, validation rules, or code. Those mechanisms are deterministic, easier to test exhaustively, and usually cheaper to run. An agent earns its place when the input contains ambiguity, unstructured text, contextual comparison, or classification that would otherwise require brittle rules or repetitive human interpretation.

Good candidates often transform information rather than authorize a final transaction. Examples include drafting a standardized summary from an existing record, categorizing an activity into one of several review queues, comparing a record with reference data, identifying the reason a record requires attention, or proposing a value for a reviewer to accept. The sales-order pricing demonstration in Acumatica documentation follows this pattern: the agent compares actual line prices with expected values retrieved through a Generic Inquiry and prepares a description of the differences.

Weak candidates combine too many business decisions. An instruction such as “review the order, decide whether the customer is trustworthy, change prices if needed, release the order, and notify everyone” mixes data retrieval, subjective judgment, financial authority, a target-form action, and communication. It is difficult to test, difficult to explain, and inconsistent with the documented boundary that an agent cannot invoke another action on the target form. Split such a process into record preparation, agent evaluation, human or rule-based approval, and deterministic execution.

Use a short selection test before configuration:

1. State the input record and the business question in one sentence.
2. Identify the smallest output that makes the next step possible.
3. List the exact fields and reference data required.
4. Define an abstain or review outcome for insufficient evidence.
5. Name the person who can judge whether the output is correct.
6. Describe how the original state can be restored or corrected.

If the team cannot answer those questions, it is not ready to write agent instructions.

Back to Table of Contents

Define the Automation Boundary Before Writing Instructions

Agent governance begins with a process contract. The contract should identify the target form, current entity, trigger, inputs, tools, fields the agent may update, permitted result values, prohibited changes, review path, and evidence retained. This contract should be approved by the process owner and technical owner before anyone spends time refining prompts.

The target form anchors the agent to a current record. Confirm that the form is a data-entry form, that the required entity is available through an endpoint, and that the intended fields can be retrieved and updated. If the Default endpoint omits a required field, decide whether extending an endpoint is justified. Acumatica warns that after an endpoint changes, tool settings in every affected agent must be updated and saved so the tools are rebuilt against the current endpoint definition. Endpoint changes therefore belong in change control, not an informal prompt-editing exercise.

Limit write scope. If the agent only needs to assign a review category and add an explanation, do not expose unrelated writable fields. If it does not need line-level updates, do not design the instructions around them. If a downstream workflow needs a status-like value, use a dedicated field with a small controlled vocabulary rather than asking the model for free-form prose that another rule must interpret.

Define what the agent must not do. Examples include changing quantities, prices, tax data, payment information, customer credit settings, posting periods, ownership, or release status. Some prohibited actions may already be impossible through the selected tools, but documenting them helps reviewers confirm that the technical configuration matches the business policy.

Finally, describe the next step independently of the agent. A workflow or business event should evaluate the saved output and determine whether a person reviews it, a notification is sent, or the record advances. This makes the process observable and allows the organization to disable the agent action without redesigning every downstream rule.

Back to Table of Contents

Build a Minimum Data Contract

An agent should receive the least data required to answer its assigned question. More context can improve a demonstration while weakening production control. Extra columns increase the chance that sensitive information is transmitted, that irrelevant details distract the model, that token consumption grows, and that a future data change alters behavior unexpectedly.

For current-record tools, document each exposed field and why it is required. Separate fields needed for reasoning from fields needed only for identification or traceability. For Generic Inquiry tools, define the inquiry owner, published screen ID, filters, returned columns, row limit, business meaning, refresh assumptions, and access restrictions. A query that was designed for human exploration may be too broad for an agent tool.

Acumatica supports adding one or more Generic Inquiry tools, each retrieving data from a single published inquiry. The tool name and description help the model decide when to call it. Use names that describe the business data and descriptions that state both purpose and limits. Avoid a generic description such as “use this for more information.” A better description explains which records the inquiry returns, what filter should be applied, and which decision the data supports.

The data contract also needs volume limits. An inquiry that returns hundreds of rows may exceed the useful context for the task, increase response time, and raise provider costs. Add shared filters and query conditions that produce only the relevant comparison set. Test with records near the expected maximum, not only with a convenient example that returns two rows.

Review the contract whenever a source changes. New columns, renamed fields, modified joins, different filters, or expanded access can change what the agent sees without any edit to its business instructions. Treat a material Generic Inquiry or endpoint change as a reason to retest affected agents.

Back to Table of Contents

Protect Sensitive Data and Understand the Masking Boundary

Acumatica AI Automation can mask selected fields returned by the get_current tool before data is sent to the LLM. The system replaces values with placeholders, keeps the actual data in Acumatica, and restores recognized placeholders when the model returns them. This is useful when an agent needs to carry a value through a result without analyzing the value itself.

Masking has operational limitations. A model cannot calculate with or classify a value it cannot see. If a numeric amount is masked, the model cannot use the actual amount to compute a percentage or compare it with a threshold. Acumatica also documents that after patch_current is invoked, an agent with masked fields cannot call get_current again. Instructions and tool sequence must account for that boundary.

Most importantly, masking on get_current does not mask columns returned by Generic Inquiry tools. Acumatica documentation explicitly warns that GI results are sent to the LLM without that masking. A governed design must therefore remove sensitive columns from the inquiry itself, apply appropriate filters, and limit returned records. Do not assume that selecting masked fields on the current-record tool protects a broad supporting inquiry.

Perform a field-level data review before production:

• Identify personal, payroll, banking, payment, tax, credential, contract, pricing, health, and regulated information.
• Decide whether the model needs to see, carry, aggregate, or ignore each value.
• Remove unnecessary fields at the source rather than relying only on instructions.
• Confirm the LLM provider, deployment, retention, regional, and commercial terms with the organization's security and legal owners.
• Review processing logs carefully because they can contain tool inputs, messages, returned data, errors, and model output.

The processing log is a governance asset and a sensitive record. Limit access to people who need it, define retention expectations, and avoid copying production logs into unsecured tickets or chat threads.

Back to Table of Contents

Write Instructions as an Executable Business Policy

Business instructions should describe purpose, required data, allowed tools, decision rules, output fields, valid values, exceptions, and stopping conditions. They should not depend on motivational language or broad requests to “use best judgment.” A reviewer should be able to compare the instructions with the process contract and identify any missing or conflicting rule.

Start with the goal and scope. Name the current record and the single decision the agent supports. Then define the tools and when to use them. Insert exact field and tool names from Acumatica rather than typing approximations. Acumatica provides an Insert Data Field command because the model must use names that match the configured tool schema.

State decision rules in observable terms. If the output is a review category, enumerate the allowed values and the evidence required for each one. Include an explicit value such as NEEDS_REVIEW when the data is incomplete, contradictory, outside policy, or unavailable. Downstream workflows should recognize that value and route it to a person instead of treating uncertainty as approval.

Separate analysis from writing. An agent that evaluates a record and generates explanatory text should first determine the controlled result, then produce a short explanation grounded in the retrieved fields. Limit length and prohibit unsupported claims. If the process needs a note for a customer or vendor, require human approval before external communication.

Add constraints that reflect actual business policy: fields that must remain unchanged, date or amount boundaries, valid currencies, permitted record statuses, maximum number of lines, and conditions that require no update. Avoid repeating constraints in contradictory ways. Acumatica notes that conflicts among system instructions, business instructions, and tool descriptions can cause processing errors.

Version the instructions. Record the approver, effective date, related agent ID, target form, endpoint version, GI versions, and test evidence. A prompt edit can change production behavior as materially as a workflow or code change.

Back to Table of Contents

Keep Human Approval at the Right Decision Point

Human review should protect the consequence, not merely observe the model. Placing a reviewer after an irreversible action provides little control. Place approval before release, payment, posting, external communication, compliance classification, account changes, or any transition that materially affects another party.

For a low-risk internal field, post-action review may be sufficient if changes are visible, reversible, and sampled regularly. For higher-risk records, the agent should write a proposal or review status rather than the final authoritative value. A workflow can assign the record to an authorized user, display the explanation, and require acceptance or correction.

Design the review screen around evidence. The reviewer needs the original value, proposed value, reason, relevant source data, and any missing or conflicting information. A bare “AI approved” flag is not enough. Acumatica's test Result tab demonstrates the value of before-and-after differences; production review should follow the same principle when possible.

Define reviewer authority and service expectations. Specify who may approve, who handles exceptions, how quickly records must be reviewed, and what happens when no reviewer acts. Avoid silently allowing an agent-generated value to become authoritative because a queue aged past a deadline.

Measure human disagreement. Corrections reveal where instructions, source data, or use-case boundaries need improvement. Preserve a reason for overrides rather than recording only that the value changed. A rising override rate should trigger investigation and perhaps automatic suspension of the action for the affected scenario.

Back to Table of Contents

Use Agent Actions in Import Scenarios Carefully

Acumatica 2026 R2 allows an import scenario to invoke an AI Automation agent action for each record it creates or updates when the AI Automation feature is enabled. This can apply judgment during a controlled import, but it also multiplies execution volume and introduces ordering requirements.

The documented action sequence is Save, agent action, and Save again. The first save creates or updates the current record so the agent has something to process. The agent reads that record and writes its result. The second save persists the agent's values. Each row uses Commit and executes for each record. The internal action name is entered manually in angle brackets because the dynamic agent action does not appear in the normal lookup.

Mapping conflicts deserve special attention. If the source file maps a value into a field that the agent also writes, the import can overwrite the model's result. Acumatica advises leaving the corresponding source values empty when the agent is responsible for those fields. Document field ownership explicitly so a future spreadsheet template or mapping change does not reintroduce the conflict.

Every imported record causes a separate LLM request sequence, and the import waits for each result. Begin with a small record count, measure processing time and token use, and verify the AI Automation History before increasing volume. Do not launch a large production import based on a successful one-record test.

Create restart and reconciliation rules. Determine how to identify records that completed the first save but not the agent action, or the agent action but not the final save. Use an import batch identifier, status field, or other traceable marker. Define whether a failed record can be retried safely and whether the agent will produce the same result when the current record already contains a partial output.

Back to Table of Contents

Orchestrate with Business Events and Workflows

An agent action becomes more useful when Acumatica configuration controls when it runs and how its result is handled. A business event can respond to a record change, schedule, or user action. A workflow can expose the agent action only in appropriate states, run it automatically, or use it in a transition. These mechanisms should remain responsible for sequence and authorization.

Use stable output values for downstream logic. Acumatica recommends instructing an agent to write one of a fixed set of values when a business event or workflow condition depends on the result. Free-form text is suitable for explanation, but it is a poor control signal. A dedicated field with values such as NO_ISSUE, REVIEW, and BLOCKED is easier to route, report, and test.

Remember that a business event fires only when its monitored value changes. If the agent writes the value already stored in the field, the event does not trigger. Design state transitions accordingly. Clearing the field before every run may create other risks, so test repeat execution and idempotency instead of assuming every successful agent call causes a new event.

Keep target-form actions separate. Acumatica states that the agent cannot invoke another action of the target form. If the process requires release, assignment, notification, creation of another document, or another command, configure that as a subsequent event or workflow step. This produces clearer logs and lets each action enforce its own rights and validation.

Add an automation stop. Administrators should know how to deactivate the agent, disable an invoking event or workflow transition, and hold affected records. Document the order of operations so an incident response does not create more partially processed work.

Back to Table of Contents

Test the Agent Before Activation

Testing must prove both correctness and containment. On the Agents form, the Test Agent function uses an example record and shows intended changes without saving those changes to the database for most agents. The Result tab identifies the affected entity and displays before-and-after values. The Processing Log records instructions, tool schemas, tool calls, responses, timing, errors, messages, and token consumption.

Build a representative test set rather than selecting only clean examples. Include ordinary records, records at policy boundaries, missing fields, unexpected detail-line counts, inactive or closed statuses, values outside normal ranges, conflicting GI results, no GI results, duplicate references, and attempts to introduce irrelevant instructions through text fields. Use de-identified or suitable nonproduction data according to organizational policy.

For every case, record the expected result before running the agent. A test is weak when reviewers decide after seeing the output that it “looks reasonable.” Compare the actual result with an approved expectation and capture differences. For classification, measure agreement by category. For generated text, define required facts, prohibited claims, maximum length, and acceptable tone.

Inspect tool behavior, not only the final wording. Confirm that the model called the expected inquiry, applied the intended filter, retrieved the correct records, and updated only the permitted fields. A plausible answer produced from the wrong data path is still a failure.

Repeat tests across model or connection changes. Agent LLM Connections can point to supported providers including Azure, Amazon Bedrock, OpenAI, and Anthropic, and providers may retire or change models. Acumatica recommends reviewing provider availability and retesting connections. A connection or model change should trigger functional regression tests, masking-placeholder tests, volume tests, and renewed approval before production use.

Back to Table of Contents

Validate Failure and Exception Paths

Production reliability depends on how the process behaves when the model, connection, data, or surrounding workflow fails. The desired failure mode is usually a visible exception with no unauthorized update, not an improvised answer.

Test invalid credentials, unavailable endpoints, provider timeouts, rate limits, missing GI permissions, empty results, malformed data, excessive record volume, noneditable fields, and an agent output that does not match the controlled vocabulary. Confirm what appears in the Result and Processing Log tabs and how operators identify the affected record.

Define retry rules. Some failures are transient, but an automatic retry can duplicate work or apply a change after the record has moved to another state. Before retrying, verify that the current record is still eligible, that earlier changes were not saved, and that the action is idempotent. Limit retry count and route repeated failures to a named queue.

Distinguish technical errors from business uncertainty. A provider timeout is a technical failure. Missing evidence or contradictory source data is a business exception. They may require different owners, communications, and service targets. Do not let a generic error status hide the cause.

Create a reconciliation view or Generic Inquiry that shows records awaiting agent processing, records completed, exceptions, last-run time, outcome, reviewer status, and related batch or workflow identifiers. This operational view is often more valuable than a polished demonstration because it enables supervisors to manage real work.

Back to Table of Contents

Monitor Activity Tokens Cost and Behavior

Each agent execution can make multiple requests to an LLM, especially when tools are called. Acumatica records token statistics calculated by the ERP and values reported by the provider. The two can differ because providers tokenize and report categories differently. Acumatica documentation states that the provider remains the source of truth for actual usage and billing.

During testing, use the Processing Log to see which requests and tool steps consume tokens. Over time, use AI Automation History ML400000 to review connection tests, agent tests, and production actions invoked by users, business events, import scenarios, or workflows. The history includes Acumatica-calculated values and provider-reported input, output, and total tokens when the provider supplies them.

A blank provider value does not necessarily mean zero usage. It may mean the provider did not report the value. Establish a reconciliation process with the provider dashboard and commercial terms. Monitor both unit economics and business throughput: cost per processed record, cost per accepted result, elapsed time, failure rate, and reviewer effort.

Behavior monitoring is equally important. Track outcome distribution, human override rate, exceptions by cause, tool-call patterns, fields changed, and volume by trigger. A sudden change may indicate new source data, a modified Generic Inquiry, a prompt edit, an endpoint change, a model update, or a shift in incoming records.

Set thresholds for investigation and suspension. Examples include a material rise in NEEDS_REVIEW, repeated writes outside expected fields, processing time that disrupts imports, provider cost above budget, or reviewer disagreement above the pilot baseline. Thresholds should initiate a defined response rather than remain dashboard decoration.

Back to Table of Contents

Establish Change Control and Audit Evidence

An AI agent is a production configuration with dependencies. Its effective behavior comes from the business instructions, system instructions, tool descriptions, endpoint entity and version, writable fields, Generic Inquiry definitions, filters, provider connection, model, invoking configuration, and downstream workflow. Change control must cover that full dependency set.

Maintain an inventory with agent ID, name, purpose, owner, target form, endpoint, tools, supporting inquiries, invoking events or workflows, output fields, approval path, connection, reviewer, activation date, and last validation date. Link the inventory entry to the approved process contract and test evidence.

Require review for material changes. A wording correction that cannot affect behavior may need lightweight review, but a new tool, field, decision rule, model, GI column, filter, or automatic trigger requires regression testing. Changes to shared endpoints or inquiries should identify every dependent agent before publication.

Preserve evidence from testing and production review without copying sensitive content unnecessarily. Useful evidence includes test case IDs, expected and actual controlled outcomes, before-and-after field differences, error classifications, timing, token totals, reviewer decision, and approval. Store logs according to security and retention policy.

Auditability also means explaining current behavior. An administrator should be able to answer why the agent could see a field, why it was allowed to update another field, which version of instructions applied, which process invoked it, and who approved activation. If those answers require reconstructing decisions from emails, the control is incomplete.

Back to Table of Contents

Use a Phased Implementation Plan

A four-phase rollout keeps the first deployment small while producing evidence for each expansion decision.

Phase one defines the process. Select one record-level use case, write the process contract, identify sensitive data, specify permitted outputs, and choose the reviewer. Confirm feature availability, licensing, target build, provider requirements, and environment policy with the appropriate Acumatica partner and internal owners.

Phase two builds in a sandbox. Configure the connection, target form, endpoint-backed tools, supporting Generic Inquiries, instructions, output fields, and manual action. Do not add an automatic trigger yet. Test representative records and correct scope, data, and instruction problems.

Phase three runs a controlled pilot. Activate the command for a limited user group or narrow queue. Require review of every result. Measure accepted results, corrections, exceptions, processing time, token consumption, and operational effort. Keep a conventional fallback process available.

Phase four automates only the proven boundary. Add a business event, workflow, schedule, or import scenario when manual pilot evidence shows consistent behavior and safe failure. Continue sampling accepted outcomes and reviewing exceptions. Expand volume, record types, or write scope one variable at a time.

Each phase needs an exit decision. The team should explicitly approve advancement, repeat the phase with changes, or stop. “No serious complaints” is not sufficient evidence. Use documented acceptance criteria and a named owner.

Back to Table of Contents

Measure Business Value Without Overclaiming

The business case should compare the governed process with its actual baseline. Relevant measures may include review time per record, queue age, percentage of records requiring manual investigation, classification agreement, correction rate, exception resolution time, processing cost, and downstream error rate. Choose measures tied to the selected use case.

Avoid treating model output volume as value. Processing more records is beneficial only when the outputs are correct enough, reviewed at the appropriate level, and used by the next process step. Likewise, a reduction in manual touches is not positive if unresolved exceptions or downstream corrections increase.

Measure accepted automation separately from assisted work. A reviewer may save time even when every result still requires approval. That can be a valid outcome and a safer long-term design for sensitive decisions. Do not force full automation merely to improve an adoption metric.

Include control costs: configuration, source-data maintenance, review, provider consumption, investigation, retraining, and change management. Agent economics can change when record volume, prompt length, tool calls, or provider pricing changes. Review the cost model with actual production history.

Report limitations with results. State the period, record population, model and connection, process version, review method, and exclusions. A pilot on one business unit and one record type does not prove enterprise-wide performance.

Back to Table of Contents

Governance Checklist Before Production Activation

Use the following checklist as a release gate:

• The process owner approved a one-sentence purpose and a bounded business outcome.
• The target form, current entity, endpoint, tools, fields, and supporting inquiries are documented.
• The agent receives only the data required for the task.
• Sensitive fields are removed, masked where supported, or otherwise governed.
• The team understands that Generic Inquiry results are not protected by current-record field masking.
• Permitted updates and prohibited changes are explicit.
• Downstream logic uses controlled values rather than interpreting free-form prose.
• Human approval is placed before consequential or irreversible actions.
• Normal, boundary, missing-data, adverse-input, error, retry, and repeat-run cases passed.
• Reviewers verified tool calls and field differences, not only final wording.
• Token use, provider billing, elapsed time, and expected volume are within budget.
• AI Automation History and operational reconciliation views are assigned to owners.
• Rollback steps can deactivate the agent and its invoking configuration safely.
• Instruction, endpoint, inquiry, workflow, and connection changes require appropriate retesting.
• A named owner approved activation and the next review date.

The checklist should be retained with implementation evidence. If an item does not apply, record the reason rather than deleting it. That creates a reviewable decision and helps future owners understand the original boundary.

Back to Table of Contents

Common Implementation Mistakes

The first mistake is starting with instructions instead of a process contract. Prompt refinement cannot repair an undefined owner, excessive write scope, or missing approval step.

The second is exposing a broad Generic Inquiry because it is convenient. Supporting inquiries should be purpose-built or carefully constrained. Remember that current-record masking does not mask GI results.

The third is combining judgment and consequence. Let the agent propose or classify, then let a person or deterministic workflow authorize the material action.

The fourth is testing one clean record. A production decision needs boundary, missing-data, conflicting-data, volume, repeat-run, and technical-failure cases.

The fifth is relying on free-form text as a workflow condition. Use fixed output values for routing and keep prose for explanation.

The sixth is ignoring dependency changes. Endpoint, GI, model, provider, instructions, and workflow changes can all alter behavior.

The seventh is assuming provider token values are always complete. Blank values can mean unreported usage, and the provider dashboard remains the billing authority.

The eighth is automating a large import too early. Each record can generate a separate execution and multiple LLM requests, so begin with a small batch and reconcile every outcome.

The ninth is presenting Acumatica AI Automation as equivalent to AI Assistant or Biz-Tech AI Analyst. Their purposes and control boundaries differ.

The tenth is treating activation as the end of implementation. Production monitoring, human feedback, exception handling, and scheduled revalidation are part of the operating model.

Back to Table of Contents

Frequently Asked Questions

What is an Acumatica AI agent

An Acumatica AI Automation agent is a configured model-driven capability associated with a target data-entry form. It can retrieve the current record, update fields and editable detail lines through endpoint-backed tools, and retrieve supporting data from published Generic Inquiries. After testing and activation, the related agent action can be invoked manually or through configured business events, workflows, schedules, or import scenarios.

Can an Acumatica AI agent create a new record

The documented agent action works with the current record on its target form and cannot create a new record on that form. A surrounding process must create or identify the record before invoking the agent. The agent may update permitted fields on that current record; other creation or action steps should be configured separately.

Can an agent run another form action?

Acumatica documentation states that an agent cannot invoke another action of the target form. Configure release, notification, assignment, transition, or other commands as separate business-event or workflow steps with their own permissions and validation.

How can agent actions be started

An active agent normally adds a command to the target form for user invocation. An action can also be invoked through a business event, import scenario, or workflow. The appropriate trigger depends on the process risk, record state, desired review point, and expected volume.

Does masking protect data returned by Generic Inquiries

No. Acumatica's documented field masking applies to selected values returned by the get_current tool. It does not mask data returned by Generic Inquiry tools. Remove sensitive GI columns, use narrow filters, limit records, and review the inquiry as a separate data boundary.

How should an agent communicate a result to a workflow

Use a dedicated field with a fixed set of permitted values, such as NO_ISSUE, REVIEW, or BLOCKED. The agent may also write an explanation, but downstream logic should not have to interpret unrestricted prose. Test repeat execution because a business event is triggered only when the monitored value changes.

Can an import scenario call an agent action

Yes, when AI Automation is enabled. Acumatica documents a Save, agent action, Save sequence for each record, with Commit selected and execution configured for each record. Start with a small batch because each record creates a separate LLM execution and the import waits for the response.

How do I estimate AI Automation cost

Review token consumption in the Processing Log during tests and in AI Automation History over time. Compare Acumatica-calculated values with provider-reported usage, and reconcile with the provider dashboard because the provider remains the source of truth for billing. Include processing volume, tool calls, retries, review effort, and support overhead.

When should a team keep human approval

Keep approval before financial posting, release, payment, external communication, compliance classification, account changes, or another material consequence. Lower-risk internal suggestions may use sampling after a controlled pilot, but the organization should retain an exception path, override evidence, and a way to suspend the automation.

What is the safest first Acumatica AI agent use case

Choose a narrow current-record task with limited data, a small controlled output, an easy human check, and a reversible result. Classification, summarization, or proposal generation is usually safer than autonomous transaction processing. Test manually before adding automatic triggers.

Back to Table of Contents

A Practical Next Step

Start with one real queue, one current record, one decision, and one owner. Write the process contract before configuring an agent. Then build the smallest tool and data boundary that can support the decision, test adverse cases, and run a reviewed pilot. Scale only the part that evidence shows to be reliable.

Biz-Tech Services can help organizations assess Acumatica AI Automation use cases, design controlled workflows and import scenarios, review Generic Inquiry and endpoint exposure, define test evidence, and establish monitoring and rollback procedures. The objective is a production process that remains understandable and governable after the demonstration ends. Explore practical implementation resources in the Biz-Tech Acumatica Lessons library or discuss a scoped automation review with Biz-Tech Services.

Back to Table of Contents

Sources

1. Acumatica 2026 R2 Integration Guide Use of Agent Actions
2. Acumatica 2026 R2 Integration Guide Agent Actions in Import Scenarios
3. Acumatica 2026 R2 Form Reference Agents ML202000
4. Acumatica 2026 R2 Integration Guide Creation of Agents
5. Acumatica 2026 R2 Integration Guide Hiding of Sensitive Data
6. Acumatica 2026 R2 Integration Guide Testing and Troubleshooting Agents
7. Acumatica 2026 R2 Integration Guide Collection of Statistics
8. Acumatica 2026 R2 Form Reference Agent LLM Connections ML201000
9. Acumatica Cloud Platform and 2026 R2 AI Overview
10. Biz-Tech Services Acumatica 2026 R2 Upgrade Guide
11. Biz-Tech Services Acumatica AI Assistant Governance Guide
12. Biz-Tech AI Analyst

Back to Table of Contents

---

by Gary

Acumatica Classic UI and Chromium XSLT: Patch and Test Before November 17, 2026

Acumatica Classic UI and Chromium XSLT: Patch and Test Before November 17, 2026

Verified October 15, 2026

Browser change has become an operational Acumatica risk. Chromium is removing XSLT support on November 17, 2026, and Acumatica has warned that Classic UI screens can stop loading in Chromium-based browsers without the applicable update. This guide gives administrators and operations leaders a focused patch, test, and communication plan - while keeping the larger Modern UI transition moving.

The deadline is a browser change with an ERP impact

On November 17, 2026, Chrome 158 is scheduled to stop supporting XSLT on Stable releases for most users. Acumatica's Classic UI relies on browser behavior affected by that change, so a Classic screen can fail to load in Chrome, Edge, or another Chromium-based browser even when the ERP server itself is healthy.

This is not simply a browser-standard discussion. A missed patch can interrupt order entry, approvals, reporting, and administration wherever a team still opens Classic UI screens. The immediate objective is continuity; the strategic objective is to reduce the remaining Classic UI footprint before the next upgrade decision.

Back to TOC

Know which environments and users are exposed

Start with a short inventory, not an assumption. Record each production, sandbox, and tenant environment; its Acumatica version and build; the hosting model; the installed patch level; the browsers employees use; and the departments that still rely on Classic UI. Include administrators, power users, remote users, and third-party support teams.

Then identify the workflows rather than only the screens. A modern home page does not prove that a month-end dashboard, a legacy pivot table, a customized inquiry, a wizard, or an ISV add-on is safe. Ask each owner to name the transaction they cannot postpone for a business day.

Back to TOC

Separate the browser patch from the Modern UI transition

The Chromium XSLT issue and the Classic UI retirement are related but different decisions. The current Acumatica notice says the updated fix is available through patches for 2026 R1, 2025 R2, and 2025 R1, while customers on 2024 R2 or earlier need a supported-version upgrade or a temporary non-Chromium workaround. Confirm the exact supported build and patch with Acumatica before making a production change.

A patch preserves near-term access to Classic UI in Chromium-based browsers; it does not eliminate the migration work. Acumatica's 2026 R2 documentation makes Modern UI the default, and Classic-only forms are warned for later retirement. Treat the patch as continuity protection while the organization completes its Modern UI plan.

Back to TOC

Build a patch decision record

For every environment, capture the current version, build, patch candidate, maintenance window, backup point, owner, validation evidence, and rollback decision. SaaS and private-cloud customers can have different delivery responsibilities, so do not infer the outcome from another customer's model. Review the current Acumatica patch notice immediately before scheduling work.

This record gives finance and operations a reliable answer to a practical question: which workflows have been proven after the change, and which still need an alternate path? It also prevents a browser update from being treated as an undocumented production experiment.

Back to TOC

Run regression tests that reflect real work

Test the browser and application together in a sandbox first. Use a supported Chromium browser at the current corporate version, then exercise the workflows identified in the inventory. Confirm login, navigation, data entry, save, release, approvals, attachments, printing or exports, dashboards, inquiries, and any custom actions that the team uses during a normal operating cycle.

For each test, preserve the expected result, actual result, timestamp, browser version, Acumatica build, and tester. Retest integrations and scheduled processes where a Classic UI setup page or manual exception path is involved. A successful landing page is not a regression test.

Back to TOC

Give users a clear contingency plan

Publish one short notice before the production window: what is changing, when it occurs, which teams should test, where to report a problem, and what to do if a screen does not load. The Acumatica notice identifies Firefox as a temporary workaround in affected situations; use it only as a controlled contingency while the applicable patch or upgrade is completed, not as a silent long-term operating model.

Assign a named business owner and technical owner for each critical workflow. During the first business cycle after the change, monitor support tickets and confirm that exception queues, approvals, and time-sensitive operations continue normally.

Back to TOC

Use the deadline to retire hidden Classic dependencies

The inventory will often uncover work that has not been modernized because it still works: custom forms, Classic dashboards, pivot tables, and legacy add-on screens. In 2026 R2, Classic UI is disabled by default, and the Beacon guidance specifically calls out forms and functionality that remain Classic-only as candidates for preparation.

Rank those items by operational risk, user volume, and replacement effort. Some may be converted, some redesigned, and some retired. Give each item an owner, target release, acceptance criteria, and a user-training date. That is a more durable response than waiting for the next upgrade window to expose the dependency.

Back to TOC

A practical 10-business-day readiness sequence

Days 1-2: finish the environment and workflow inventory, confirm the current Acumatica advisory, and choose a patch candidate. Days 3-4: apply the patch in sandbox and execute the regression pack with business users. Days 5-6: resolve failures, validate customizations and ISV components, and document the production plan. Days 7-8: communicate the change and prepare the support rota. Days 9-10: apply the approved patch in production, run smoke tests, and track results through the next critical business cycle.

If the timeline is already compressed, reduce scope only after protecting the highest-risk workflows. Do not skip version confirmation, backup planning, or a post-change verification simply to meet the date.

Back to TOC

Why XSLT removal matters to Acumatica Classic UI

XSLT, or Extensible Stylesheet Language Transformations, is a browser technology that can transform XML data into a format a user can view and work with. Chromium has deprecated the browser-side XSLTProcessor API and the XML stylesheet processing instruction, with removal planned for Chrome 158 on November 17, 2026. That browser decision is broader than Acumatica, but it matters to Acumatica because portions of the Classic UI depend on the browser behavior being removed.

The operational symptom can be deceptively simple: a Classic UI screen that worked yesterday may stop loading after a browser update. Users may initially report a blank page, incomplete rendering, or a screen that appears to hang. Because the server can remain available and Modern UI screens can continue working, the incident may look inconsistent across departments. That inconsistency is exactly why organizations need an inventory tied to real workflows rather than a generic statement that the site is available.

The change also demonstrates an important dependency-management lesson. ERP continuity depends not only on application code and infrastructure but also on browsers, identity services, document engines, operating systems, and third-party components. A mature readiness plan records those dependencies, assigns ownership, and tests them together before a vendor deadline becomes a production outage.

Back to TOC

Understand the October 2026 change before the November deadline

Acumatica's original guidance focused on Chromium's planned November removal. The October 1, 2026 update added urgency: an unexpected Chromium behavior change caused Classic UI problems to surface earlier than anticipated and required updated fixes. Acumatica listed expedited patch dates for 2026 R1, 2025 R2, and 2025 R1. Organizations should therefore avoid treating November 17 as the first possible impact date.

This changes the planning sequence. Administrators should first verify whether their current browser and Acumatica build already show the issue, then confirm whether the environment contains the updated fix rather than only an earlier patch intended for the original removal schedule. A patch name or installation date is not enough evidence. The change record should identify the exact Acumatica build, the patch source, the browser version used for testing, and the date the current vendor notice was checked.

If a team already experienced intermittent Classic UI failures, the incident evidence should feed the regression pack. Capture affected screen IDs, browser versions, console or network symptoms when available, user roles, customizations, and whether the same transaction succeeds in Modern UI or Firefox. This turns an urgent support event into a repeatable validation scenario instead of relying on memory after the patch is installed.

Back to TOC

Map the Acumatica version and hosting model

The correct response depends on both the Acumatica release and who is responsible for applying updates. Acumatica's current notice distinguishes environments on 2025 R1 or later from those on 2024 R2 or earlier. It also distinguishes SaaS delivery from private-cloud subscription environments. Those distinctions determine whether a fix may be delivered automatically, whether a customer must schedule a patch, or whether a supported-version upgrade is required.

Create one row per environment and include production, test, training, disaster-recovery, and integration tenants. Record the full version and build, hosting model, responsible administrator, maintenance process, browser-management policy, installed customizations, and business owner. Do not assume a sandbox matches production merely because the two environments share a major release. Patch history, customization packages, data volume, and authentication configuration can differ.

The inventory should also name the partner or internal team that can confirm patch eligibility. If an environment is outside the versions covered by the current fix, the decision becomes an upgrade and continuity decision rather than a normal patch. That requires additional time for customization validation, integration testing, data refresh, user acceptance, and change approval. Escalate that gap immediately instead of leaving it inside a technical checklist.

Back to TOC

Create a dependable Classic UI dependency inventory

A useful dependency inventory starts with people and transactions. Ask department leads which processes still require a Classic UI screen and when those processes become time-critical. Examples include order release, shipment processing, cash management, month-end reconciliations, time entry, project billing, manufacturing exceptions, construction commitments, and administrative setup. The goal is to connect each screen to a business outcome and recovery priority.

Next, inspect technical sources. Review site maps, customization projects, access-right assignments, Classic dashboards, pivot tables, wizards, custom forms, and ISV documentation. Search support tickets for terms such as Classic UI, legacy screen, switch interface, blank page, browser, dashboard, or pivot. Ask power users to demonstrate shortcuts and exception paths because those are often absent from formal process documentation.

For every dependency, record the screen ID, workflow, user group, frequency, peak period, customization owner, Modern UI status, test owner, and fallback. Add a confidence field so unverified assumptions are visible. A screen marked as available in Modern UI is not complete until a business user confirms that the required fields, actions, imports, attachments, reports, and navigation behavior support the real transaction.

Back to TOC

Prioritize workflows by operational risk

Not every Classic UI dependency deserves the same response. Prioritize the inventory using business impact, time sensitivity, transaction volume, number of affected users, availability of a workaround, customization complexity, and recovery effort. A rarely used inquiry with a documented Modern UI replacement is different from a release screen that controls daily shipping.

A practical classification uses three tiers. Tier 1 covers workflows that can stop revenue, payment, regulatory, payroll, shipment, or customer-service operations within hours. Tier 2 covers important work that can tolerate a short delay but creates a growing backlog. Tier 3 covers low-frequency administrative or analytical tasks with a workable alternative. The exact labels matter less than having owners agree on the order of testing and recovery.

Risk ranking also helps when time is limited. If the organization cannot execute every test before the maintenance window, it can protect Tier 1 workflows first, document the residual risk, and schedule the remaining validation. The ranking should be approved by process owners, not assigned by IT alone, because technical teams may not know which seemingly small action closes a financial period or releases a customer commitment.

Back to TOC

Design the sandbox before applying the patch

A sandbox is valuable only when it represents the production conditions relevant to the change. Confirm that it uses the intended Acumatica build, customization packages, ISV components, authentication method, browser policies, and representative roles. Refresh data when necessary to reproduce critical transactions, while following the organization's privacy and data-handling rules.

Freeze the test baseline before patching. Record the current browser version and execute a small set of control tests so the team knows which issues already exist. Then apply the candidate patch using the same documented sequence planned for production. Capture start and finish times, installer output, service status, application startup behavior, and any manual configuration changes.

After patching, confirm basic health before business testing begins. Verify login, navigation, background processing, scheduled jobs, integrations, printing, email, and access to both Modern and remaining Classic UI screens. If the sandbox contains unrelated experimental changes, identify them clearly or create a cleaner environment. Otherwise a failed test can lead to hours of investigation against the wrong cause.

Back to TOC

Build browser coverage around the real desktop estate

Chrome and Microsoft Edge are the most visible Chromium-based browsers in many organizations, but the testing scope should come from the managed desktop estate. Record supported browsers, release channels, update policies, virtual desktop images, kiosk devices, remote-access platforms, and any embedded browser components used by companion applications. Confirm whether updates are centrally controlled or can arrive independently on user devices.

Use the current corporate browser version for the main regression cycle and include the next available managed version when practical. This is especially important when the organization delays browser updates, because a sandbox tested on an administrator's current browser may not represent a warehouse workstation or remote desktop pool. Capture the full browser version in every result, not simply Chrome or Edge.

Do not use compatibility modes or alternate browsers as invisible permanent fixes. A temporary workaround can protect continuity, but it should have an owner, an expiration date, a deployment method, and security approval. The supported application patch and the Modern UI transition remain the durable paths. Browser exceptions that outlive the incident can create a second unmanaged dependency.

Back to TOC

Test authentication session and navigation behavior

Begin the functional test pack with the path users take before they reach a transaction. Validate single sign-on or native login, multifactor redirects, tenant selection, company and branch selection, session timeout, logout, and reauthentication. Confirm that bookmarked Classic UI URLs, navigation favorites, and links from notifications still land on the intended page.

Mixed-interface environments deserve special attention. Test navigation from a Modern UI page to a Classic-only page and back again. Verify that the user's role, branch, locale, and session context remain correct. If the organization uses multiple tabs, confirm that common tab patterns do not produce stale sessions or unexpected redirects after the patch.

Record any difference between a direct URL, a site-map link, and a workflow action that opens another screen. A page may render successfully when opened directly while a contextual action passes parameters differently. Tests should therefore begin from the same starting point users follow in normal work rather than launching every screen from an administrator's saved link.

Back to TOC

Validate data entry and transaction completion

For each critical workflow, test the transaction from creation through its business endpoint. Confirm field defaults, selectors, date and quantity entry, validation messages, saves, releases, approvals, reversals, attachments, notes, and follow-up navigation. Use realistic roles and data conditions so field security and automation behave as they do in production.

Include positive and negative cases. A successful order entry proves only the normal path. Test missing required fields, credit holds, inventory shortages, approval rejection, failed integrations, duplicate references, and other exceptions the team resolves in Classic UI. These paths often open additional dialogs or screens and are more likely to expose a hidden dependency.

Reconcile the result in the database-facing application screens and downstream business records. For example, confirm that a released document has the expected status, related batch, inventory effect, and audit trail. Browser compatibility testing is not complete if the page looks correct but the transaction produces incomplete or duplicated business data.

Back to TOC

Test reports dashboards pivots and exports

Reporting components deserve their own workstream because they combine browser rendering, parameters, data retrieval, printing, and export behavior. Inventory Classic dashboards, pivot tables, report forms, inquiry exports, and links distributed by email or documentation. Identify which ones support executive, compliance, customer, and month-end decisions.

For each report, test parameter entry, date ranges, branch restrictions, drill-down links, pagination, printing, PDF output, Excel export, and scheduled delivery where applicable. Compare totals and row counts with a known baseline. Visual success is not sufficient if the exported file changes columns, formats dates differently, omits rows, or loses filters.

Acumatica's 2026 R2 transition guidance specifically calls out Classic dashboards and pivot tables among the items organizations should prepare for Modern UI. Use the browser-readiness exercise to decide which assets should be rebuilt, replaced with Generic Inquiries, moved to a supported dashboard experience, or retired because no one uses them. Confirm ownership before deleting or redesigning anything.

Back to TOC

Validate customizations and ISV solutions

Customizations can preserve business value while also increasing uncertainty during a platform change. Build a list of customization projects, custom screens, modified actions, JavaScript, themes, external widgets, and ISV packages that touch the Classic UI. Record the publisher, source repository or package location, current version, and support contact.

Ask each owner whether a Modern UI version is available and whether the current package has been certified for the target Acumatica patch. Do not treat the absence of a vendor warning as confirmation. Request written compatibility guidance for components that affect Tier 1 workflows, and retain that response with the change evidence.

Regression tests should cover both the visible customization and its side effects. Confirm custom fields, selectors, calculations, actions, pop-up dialogs, file handling, automation schedules, and data sent to integrations. If a workaround requires temporarily disabling a customization, document the business consequence and the precise steps for restoring it. Avoid making emergency production edits that cannot be reproduced in source control.

Back to TOC

Protect integrations and automated processes

Many integrations run without a browser, but their configuration, monitoring, and exception handling may still rely on Classic UI pages. Inventory API connections, import and export scenarios, scheduled processes, email processing, commerce connectors, bank feeds, tax services, document capture, and robotic automation. Identify the screen an administrator uses when a job fails.

Test routine execution and at least one controlled exception. Confirm credentials, endpoint behavior, queues, retry logic, logs, and reconciliation. If users normally open a Classic screen to correct a rejected record, validate that recovery path explicitly or provide a Modern UI alternative before the browser change reaches production.

Desktop automation deserves special scrutiny because it may depend on page structure rather than supported APIs. A patch or interface change can break selectors even when a human user sees a functional screen. Record every bot or script that interacts with the browser, rerun it in the patched sandbox, and prefer a supported integration approach when redesign is practical.

Back to TOC

Define evidence and acceptance criteria

A readiness decision should be based on evidence that another reviewer can understand. For each test, store the environment, Acumatica build, browser version, user role, test data, steps, expected result, actual result, screenshots when helpful, defect reference, tester, and date. Link the evidence to the change ticket rather than leaving it in personal notes or chat.

Acceptance criteria should describe business completion. Replace vague results such as screen opens with outcomes such as warehouse user creates and confirms a shipment, prints the required document, and verifies the released status using the assigned role. This wording makes it harder to close a test before the transaction reaches its real endpoint.

Classify defects by operational impact and assign a disposition: fix before production, accept temporarily with a documented workaround, remove the dependency, or defer with business approval. Re-run failed tests after any patch or configuration change. A final readiness summary should show passed Tier 1 workflows, unresolved risks, owners, and the explicit go or no-go decision.

Back to TOC

Plan backup rollback and recovery

The production plan should state what is being backed up, who verifies the backup, how long restoration would take, and what data could be created between the change and a rollback decision. Coordinate application, database, file storage, customization, and configuration backups according to the hosting model and established support procedures.

Define rollback triggers before the maintenance window. Examples include failed login for a critical population, inability to complete a Tier 1 transaction, widespread Classic UI rendering failure, corrupted output, or integration backlog beyond an approved threshold. Name the person authorized to call the rollback and the latest time that decision can be made safely.

A browser workaround can be part of recovery, but it is not identical to restoring the application. If Firefox is approved as a temporary path, prepare installation, security policy, bookmarks, user instructions, and support ownership in advance. Test the workaround with the same critical roles. Remove the temporary configuration once the supported patch path is stable.

Back to TOC

Communicate with users before and after the change

User communication should be specific enough to change behavior without overwhelming people with browser-engine detail. Tell affected users which workflows are in scope, the maintenance window, what normal behavior should look like, how to report a blank or incomplete screen, and whether a temporary browser is approved. Include screenshots or screen IDs when teams use similar names for different functions.

Ask department leads to nominate testers and confirm availability during the validation window. For shift-based operations, include warehouse, field, or production users who may not read the same channels as office teams. Provide a short script for the service desk so reports are tagged consistently with browser version, screen ID, time, user role, and business impact.

After deployment, send a clear completion notice only when the smoke tests pass. If risk remains, state the affected workflow, workaround, owner, and next update time. During the first full business cycle, monitor tickets and transaction queues. Close the change after process owners confirm that operations are stable, not immediately after the technical installation finishes.

Back to TOC

Coordinate finance operations IT and leadership

The deadline crosses organizational boundaries. IT owns browser deployment, infrastructure coordination, backups, and technical change control. Acumatica administrators own version verification, patch planning, security roles, and application evidence. Process owners define critical transactions and acceptance. Leadership resolves schedule conflicts and accepts residual business risk.

Finance should identify period-close, payment, billing, and reconciliation windows that restrict change timing. Operations should identify shipping, receiving, manufacturing, field, and customer-service peaks. Security should review temporary browser exceptions and access implications. The service desk should know how to distinguish a browser-rendering issue from authentication, network, or application availability problems.

Use one readiness meeting with a concise decision pack rather than several disconnected technical updates. The pack should show environment status, critical workflow results, open defects, rollback readiness, user communication, and the Modern UI follow-up plan. That structure keeps the immediate patch decision focused while making long-term dependencies visible to leaders who control resources and priorities.

Back to TOC

Move from emergency patching to Modern UI readiness

The patch reduces the immediate Chromium risk, but organizations should use the resulting inventory to plan Modern UI work. Acumatica's direction is clear: Modern UI is the default in 2026 R2, users cannot normally switch interfaces when a Modern version exists, and Classic-only functionality is moving toward retirement. A successful patch should therefore buy controlled migration time, not justify indefinite delay.

Group remaining items into standard screens, configuration differences, custom screen conversions, dashboards and pivots, training gaps, ISV dependencies, and process redesign. Estimate each group separately because the skills and validation effort differ. A custom screen may require TypeScript and layout work, while a familiar standard screen may need only role-based testing and training.

Set milestones around business workflows rather than raw screen counts. Completing ten low-value screens does not reduce risk if the only shipping exception process remains Classic-only. Prioritize items by the same operational tiers used for browser testing, and require a business owner to accept the Modern UI result. Update process documentation and support materials as each dependency is retired.

Back to TOC

Measure readiness with useful operational metrics

Metrics should reveal whether risk is shrinking. Track the number of Classic UI dependencies by tier, percentage with a confirmed Modern UI path, percentage of Tier 1 tests passed, environments on the approved patch, open defects by severity, users trained, and workflows still dependent on a temporary workaround. Report trends and owners, not only a single green status.

After production deployment, measure failed-page incidents, service-desk volume, transaction backlog, workaround usage, and time to resolve browser-related reports. Compare these results with the baseline. A low ticket count can indicate success, but it can also mean users created manual workarounds without reporting them, so check with process owners during the first critical cycle.

For the Modern UI program, add adoption and quality measures: active users by interface, custom screens converted, acceptance tests completed, unresolved behavior gaps, and time spent supporting legacy paths. Review the metrics monthly until Tier 1 Classic dependencies reach zero. Retire emergency browser policies and temporary documentation as soon as the supported operating model is stable.

Back to TOC

Common mistakes that increase deadline risk

The first mistake is assuming that an automatic SaaS update removes the need for testing. Delivery responsibility and business acceptance are different. The second is checking only the home page. A mixed-interface tenant can appear healthy while a specific Classic workflow fails. The third is recording a major version without the full build and current patch evidence.

Other common failures include testing only with an administrator, excluding exception paths, overlooking Classic dashboards and pivots, forgetting third-party add-ons, and using a temporary browser without security approval. Teams also lose time when results are stored in chat messages instead of a shared test record, or when no one has authority to decide whether a defect blocks deployment.

The most expensive mistake is treating the compatibility fix as the end of the project. That leaves the organization exposed to the next browser or platform change and compresses the Modern UI migration into a later upgrade window. Use the November deadline as a forcing function to create accurate ownership, reusable tests, and a funded retirement plan for the remaining legacy dependencies.

Back to TOC

Executive decision checklist

Before approving production work, leaders should be able to answer the following questions. Do we know every production and sandbox version? Have we confirmed the current Acumatica patch guidance? Are all Tier 1 Classic workflows identified and tested in the managed browser estate? Are customizations, ISV products, reports, integrations, and exception paths included? Is the backup and rollback decision documented? Are users and the service desk prepared?

They should also ask what remains after the patch. Which Classic dependencies lack a Modern UI path? Which items block a future 2026 R2 or later upgrade? Who owns each conversion, validation, or vendor escalation? What is the target date for removing temporary browser workarounds? How will progress be measured and reported?

A responsible go decision does not require zero defects, but it does require transparent residual risk, named owners, workable contingencies, and business acceptance. If those conditions are absent, the correct action is to adjust the window or reduce risk before proceeding. The November date is important, but an undocumented emergency change can create more disruption than the browser change it is intended to prevent.

Back to TOC

Production cutover runbook

The cutover runbook should convert the approved plan into a timed sequence that anyone on the change team can follow. Begin with a readiness checkpoint confirming the maintenance window, backup completion, patch package, administrator access, tester availability, communication status, and rollback authority. Record the starting Acumatica build and browser versions before anyone changes the environment.

During implementation, log each action and its result. Typical steps include pausing scheduled work when required, applying the approved patch, restarting relevant services, confirming application availability, validating login, and releasing the environment to smoke testers. Avoid adding unrelated configuration or customization changes to the same window. A narrow scope makes troubleshooting and rollback decisions faster.

The smoke-test order should follow business risk. Test authentication and one high-value transaction first, then complete the remaining Tier 1 scenarios, integrations, reports, and exception paths. Establish a time limit for investigation so a difficult defect does not consume the rollback window. Record whether the team proceeds, pauses, uses a temporary contingency, or restores the previous state.

Close the maintenance window with a formal handoff. Confirm the final build, browser results, open issues, workaround status, monitoring owners, and next communication time. Preserve the runbook and evidence because the same tests can support a later patch, browser release, or Modern UI conversion. A reusable runbook turns one deadline response into a stronger operational control.

Back to TOC

First business day monitoring plan

The highest-value monitoring occurs when users resume normal work. Staff the service desk and application team around the first order cycle, shipment wave, approval run, scheduled integration, and financial processing period. Ask process owners to report both failures and unexpected manual steps. A workflow can technically complete while taking much longer or forcing users into an undocumented workaround.

Create a focused incident category for Classic UI and Chromium reports. Collect the user, time, browser version, Acumatica build, screen ID, navigation path, screenshot, and business impact. Compare similar reports before changing the system; several departments may be seeing one shared issue. Separate browser rendering problems from access rights, network latency, stale cache, customization defects, and unrelated application errors.

Monitor server and application indicators alongside user feedback. Review error logs, background job status, integration queues, email processing, scheduled reports, and transaction backlogs. If the organization deployed a temporary alternate browser, track who uses it and for which workflows. That usage is a measurable residual dependency and should decline after the supported fix is confirmed.

At the end of the first business day, issue a concise status summary: transactions tested, incidents received, resolutions, outstanding risks, and the next review point. Continue monitoring through the next critical weekly or month-end cycle if those processes were not exercised during the initial window. Do not close the change solely because the maintenance period ended without an alert.

Back to TOC

Long term governance for browser dependent ERP features

Browser dependencies should become part of the ERP governance model. Add supported browsers and managed versions to the platform standard, identify who reviews browser deprecation notices, and connect that review to Acumatica release and patch management. Include browser changes in the same calendar used for operating-system, identity, database, and integration dependencies.

Maintain a reusable compatibility test pack with role-based transactions, reports, customizations, and exception paths. Run a focused subset before major browser deployment and the full pack for high-risk application or platform changes. Automate evidence collection where it is reliable, but retain human acceptance for workflows whose success depends on business judgment, usability, or printed output.

Governance should also prevent new Classic dependencies. Require new customizations and ISV purchases to state their Modern UI support, browser requirements, upgrade policy, and test responsibility. Review existing custom work during each Acumatica upgrade cycle and remove assets that no longer have an owner or business purpose. This reduces the volume of emergency analysis during future deadlines.

Finally, keep leadership informed through a small set of operational measures: unsupported environments, Tier 1 legacy dependencies, patch compliance, open vendor gaps, and Modern UI conversion progress. The purpose is not to create more reporting. It is to make hidden platform risk visible early enough that the organization can schedule work before an external vendor date controls the timetable.

Back to TOC

Patch validation checklist

Confirm the target Acumatica version and exact patch against the latest vendor notice. Verify backup and rollback ownership. Test a Chromium browser in sandbox. Exercise each critical Classic UI workflow from login to completion. Validate custom screens, reports, dashboards, pivot tables, attachments, exports, and approval steps. Record results. Communicate the production window and contingency browser. Complete production smoke tests and keep the evidence with the change record.

Back to TOC

Frequently Asked Questions

Will the November 17, 2026 date affect every Acumatica customer? The exposure depends on version, patch level, browser, and whether users still rely on Classic UI. Verify the current Acumatica notice for your environment.

Does applying the patch remove the need to move to Modern UI? No. It addresses browser continuity; it does not replace the migration and customization work required for the Modern UI direction.

Can Firefox be the permanent answer? Treat it as a temporary contingency only. It may preserve access in some scenarios while you complete the supported patch or upgrade path.

Which items need the most careful testing? Custom screens, Classic-only forms, dashboards, pivots, workflow exceptions, ISV components, and actions used during time-sensitive business cycles should be explicit test cases.

What should a PCS customer do? Confirm the applicable patch and installation process with Acumatica or your partner, then patch and validate before the deadline.

What should a SaaS customer do? Confirm the delivered patch status and validate business-critical workflows in your tenant; automatic delivery does not replace acceptance testing.

Can an organization still use Classic UI in 2026 R2? The current documentation says Classic UI is disabled by default in 2026 R2, with limited legacy access mechanisms and remaining Classic-only functionality warned for later retirement. Confirm the exact release guidance before planning.

When should the work start? Immediately. The October 2026 browser behavior change described in Acumatica's updated notice means waiting until November can leave too little time for a controlled regression cycle.

Back to TOC

Sources

• Chrome for Developers: Removing XSLT for a more secure browser
• Acumatica Community: Chromium XSLT Deprecation Affecting Classic UI
• Acumatica Community: Classic UI Deprecation in 2026 R2 and FAQ
• Acumatica Beacon: Customization Update to 2026 R2 - Retirement of the Classic UI

Biz-Tech Services can help teams inventory Classic dependencies, validate patches, and plan a controlled Modern UI transition without losing sight of business-critical workflows.

---

by Gary

Acumatica AI Assistant in 2026 R2: Use Cases, AI Units, GI Security, and Governance

Acumatica AI Assistant in 2026 R2: Use Cases, AI Units, GI Security, and Governance

A practical guide to governed reporting, AI Units, Generic Inquiry security, and rollout controls.

Why AI Assistant governance is an operating issue

AI Assistant makes ERP reporting more conversational: a user can ask a business question in ordinary language and receive a text answer, table, chart, or pivot table. That convenience can remove a real bottleneck for finance, operations, and project teams that otherwise wait for a report or build a one-off inquiry. It also changes the operating model. The quality, relevance, and visibility of answers are shaped by the Generic Inquiries that administrators choose to expose, the descriptions that make those inquiries understandable, and the roles assigned to users. Governance is therefore not an after-the-fact security review. It is the design work that determines what the assistant can reliably answer and who can use it.

For a 2026 R2 organization, the practical question is not whether natural-language access to ERP data is valuable. It is whether the business can introduce it with a defined data boundary, an accountable owner, a measured usage model, and a review path for decisions that matter. This guide explains how to set that foundation. It focuses on reporting and analysis, where an assistant can accelerate discovery while people remain responsible for interpretation, approval, and action.

Back to TOC

What Acumatica AI Assistant is and is not

Acumatica AI Assistant is a natural-language interface embedded in Acumatica. In the documented 2026 R2 experience, it can answer questions using Generic Inquiries configured by an administrator, preserve context within a conversation, and display information as text, lists, tables, charts, or pivot tables. A useful governance principle follows directly from that design: the assistant is not a general, unrestricted search engine over the ERP database. Its useful data scope is the intentionally exposed inquiry set.

It is also important not to overstate what it does. The official FAQ describes AI Assistant as limited to querying data through configured and exposed Generic Inquiries; it does not update records or perform actions. That boundary makes the first rollout easier to contain, but it does not eliminate the need for oversight. A response may still be misunderstood, based on an inappropriately broad inquiry, or used as the basis for a decision without the correct business context. Treat AI Assistant as a governed analysis interface, not as an autonomous decision maker.

Back to TOC

What changed for AI Assistant in 2026 R2

Acumatica states that AI Assistant became generally available with the 2026 R2 release for customers on 2026 R1 and later, subject to obtaining it through the customer subscription process. The 2026 R2 materials also describe context-aware assistance, a self-aware capability that can state its limits, a Help Agent informed by Beacon content, and the ability to turn a question into a dashboard widget. These changes make the assistant more visible to business users, which is exactly why role design and operational ownership should be settled before broad enablement.

General availability should not be read as a signal to enable everything at once. Availability, licensing, entitlement, and actual behavior should be checked in the target tenant before publication or rollout. A controlled pilot lets the organization validate the version, enabled features, user experience, inquiry results, and AI Unit consumption on its own data. That evidence is more useful than assumptions drawn from another customer, another edition, or an earlier release.

Back to TOC

Start with business questions rather than with a feature list

The best first questions are narrow, repeatable, and already familiar to the business. A controller might want to review open receivables by aging band and customer class. A purchasing manager might want to identify overdue purchase orders with a material impact on customer commitments. A project leader might want to compare actual cost with budget for active projects. Each question has a clear owner, a recognizable source of truth, and a result that a person can validate against an existing report or inquiry.

Avoid beginning with questions that combine confidential data, undefined metrics, or many competing exceptions. “Which customers are risky?” sounds useful, but it depends on a governed definition of risk, appropriate data access, and human judgment about how the result will be used. Start by documenting the question, expected output, intended audience, data owner, and a simple acceptance test. If a result cannot be reconciled to a trusted baseline, the inquiry or its descriptions need work before more users depend on it.

Back to TOC

Make Generic Inquiry exposure a deliberate data boundary

Generic Inquiries are the central governance control for AI Assistant. Acumatica documentation explains that an administrator can select Expose to AI Assistant on a published inquiry, add descriptions for the inquiry, fields, and parameters, and process the descriptions through AI Assistant Data Processing. The assistant then works from that approved set. An exposed inquiry is not merely a reporting artifact; it becomes a curated interface between users’ natural-language questions and business data.

Use a small, reviewable inventory. For every candidate inquiry, record the business purpose, owner, audience, sensitive fields, key filters, expected refresh behavior, and review date. Remove experimental inquiries from the initial set. Prefer purpose-built inquiries over broad “everything” inquiries, and test them with representative users. When an inquiry changes materially, re-evaluate its exposure and reprocess its AI description. This limits accidental scope expansion and gives the organization a clear answer when someone asks what the assistant is allowed to use.

Back to TOC

Design roles and access before enabling users

The official FAQ says AI Assistant inherits access rights defined on each Generic Inquiry, so users see only data they are authorized to view. It also notes that administrators initially have access and additional users need the AI Assistant User role. Inherited security is valuable, but it is not a substitute for reviewing whether the underlying inquiry itself expresses the intended business boundary. A user who legitimately has broad inquiry access may still not be the right audience for a broadly exposed conversational analysis experience.

Map access in three layers: application roles, inquiry access, and the AI Assistant User assignment. Ask who should ask questions, which inquiries they should be able to use, and who can change the inquiry definitions. Separate ordinary business users from people who administer exposed inquiries. Test with non-administrator pilot accounts, including edge cases such as regional managers, temporary staff, and users with mixed finance and operations responsibilities. Document removals as carefully as grants, because a role change may be the fastest way to reduce exposure when an issue is found.

Back to TOC

Write descriptions that improve answers without revealing more data

AI descriptions help the assistant associate business language with the right inquiry, field, and parameter. They should explain what a measure means, the period it covers, the intended use, and any important caveat. For example, an “open invoice balance” field description can clarify whether it excludes disputed documents, whether the amount is in base currency, and which date drives aging. Clear descriptions reduce ambiguous questions and make it easier for users to recognize whether an answer fits the decision at hand.

Descriptions should not become a secondary data store. Do not put credentials, private customer notes, hidden operating procedures, or sensitive assumptions into a description simply because it is convenient. Use a review checklist that includes accuracy, business terminology, security sensitivity, and ownership. If a query depends on a parameter, write a clear instruction for that parameter so users understand the boundary rather than receiving a plausible-looking result built on an accidental default.

Back to TOC

Establish an AI Units budget and monitoring routine

AI Units are Acumatica’s measure of AI Assistant consumption. Acumatica describes them as reflecting a blend of model input, output, and cache tokens, and identifies the AI Unit Consumption screen and License Monitoring Console as places to monitor usage. If the monthly allocation is exhausted, the assistant is unavailable until the allocation resets or additional units are obtained. That makes consumption monitoring both a financial and a continuity control.

Set a monthly owner and an escalation threshold before launch. During a pilot, measure consumption by use case rather than only in aggregate: recurring executive questions, exploratory analysis, training activity, and repeated retries can have very different patterns. Review sudden changes in use as an operational signal. A spike may reflect strong adoption, confusing descriptions, an overly broad prompt pattern, or a process that should be served by a saved dashboard instead. Publish a simple user guideline: ask concise, specific questions; review the proposed result; and use established dashboards for routine monitoring where that is a better fit.

Back to TOC

Create a human review policy for decisions and exceptions

A conversational answer can be a useful starting point, but it should not silently replace a controlled business decision. Define categories that always require source verification or a second reviewer: payment holds, credit decisions, payroll-related analysis, pricing exceptions, vendor selection, project write-offs, and anything involving regulated or confidential data. The policy can be brief, but it should tell users when an AI Assistant response is informational, when it must be reconciled, and where the authoritative record remains.

For every pilot use case, decide what evidence a user should retain. In some cases a link to the inquiry result and a saved report is sufficient. In others, a supervisor approval or an exported reconciliation may be appropriate. The goal is not to create bureaucracy around simple questions. It is to ensure that a polished chart or summary does not conceal an unverified interpretation, a stale filter, or a missing exception.

Back to TOC

Treat data sensitivity as a design input

Data classification should influence which inquiries are exposed, how they are filtered, and which roles receive access. Financial figures, customer information, employee data, health information, project margins, and personally identifiable data do not all have the same handling requirements. Start with the classifications already used by the organization, then evaluate the fields included in each proposed inquiry. If an inquiry mixes useful operational data with highly sensitive fields, consider a separate, least-privilege inquiry for the AI use case.

Acumatica states that AI Assistant temporarily stores a user prompt and a record that a tool call succeeded, rather than the underlying data itself, to support follow-up questions; it also states that customer data is not used to train foundational models. Those statements are helpful, but a rollout team should still review the current contractual terms, regional requirements, retention expectations, and internal policies with the appropriate security and legal stakeholders. Do not turn a product statement into a blanket compliance conclusion.

Back to TOC

Use a pilot that can prove or disprove the rollout assumptions

A pilot should be small enough to observe and broad enough to surface real differences in language, roles, and workflows. Select a cross-functional group such as a finance analyst, operations manager, project manager, IT administrator, and the business owner of each inquiry. Give them a short set of tested questions, then allow additional questions that they record for review. Capture whether the assistant selected the appropriate inquiry, whether the result reconciled to an existing source, whether the wording was clear, and whether the user knew what to do next.

Define entry and exit criteria. Entry criteria might include published and reviewed inquiries, completed role tests, named owners, a consumption threshold, and user training. Exit criteria might include an agreed accuracy rate for the approved question set, no unresolved access issues, a documented support path, and a decision about the next inquiry group. A pilot is successful when it produces trustworthy evidence, not merely when participants say the experience is impressive.

Back to TOC

Measure quality, safety, adoption, and business value together

Do not reduce governance to a security checklist. Track four categories: quality, safety, adoption, and value. Quality can include reconciliation success for approved questions and the percentage of answers that required inquiry changes. Safety can include access-test results, sensitive-data incidents, and completed reviews of exposed inquiries. Adoption can include active users, repeat use by role, and the types of questions users ask. Value can include time saved in recurring reporting, fewer manual report requests, or faster exception identification where the business can credibly measure it.

Use the measures to decide what to improve. Low adoption might mean training is weak, but it can also mean the first inquiries are not valuable. High use with low trust is a warning sign, not a victory. A modest set of reliable, owned questions usually creates more lasting value than a large set of ambiguous inquiries that users cannot explain or reconcile.

Back to TOC

Plan for changes to data, roles, models, and releases

Governance is ongoing because the system changes. New customizations can add fields and tables. An inquiry can be revised. A person’s role can change. Acumatica can release an update that affects availability or behavior. Establish a lightweight change process: identify the changed asset, assess whether it is exposed to AI Assistant, re-test the relevant question set, reprocess descriptions where required, and update the inventory. Schedule periodic access reviews and a quarterly review of active inquiries, usage, and unresolved user feedback.

Release planning deserves special attention. Before an upgrade, validate the AI Assistant feature state, role assignments, exposed inquiries, data-processing status, key outputs, integrations around reporting, and the current contractual or entitlement details. Keep the test evidence with the upgrade record. This turns AI Assistant from an untracked convenience into a managed part of the ERP reporting estate.

Back to TOC

How Biz Tech AI Analyst fits into the conversation

Biz-Tech AI Analyst is separate from Acumatica AI Assistant. According to Biz-Tech product documentation, it is an Acumatica customization package that lets business users describe a reporting need in plain language. It can propose a new report or Generic Inquiry, explain its intended columns, tables, filters, and grouping, and build it only after the user approves the proposal. It can also propose changes to existing reports and inquiries, while preserving versions for reports and offering an undo path. It is designed to help business users create or refine reporting artifacts without writing SQL or BQL.

The distinction matters for governance. Acumatica AI Assistant is a governed question-and-answer experience over administrator-exposed Generic Inquiries. Biz-Tech AI Analyst is intended to help users create or change report and inquiry definitions within their assigned Acumatica rights and approval flow. Its documentation states that it does not insert, change, or delete business data; it creates or changes report and inquiry definitions. Organizations considering both should define separate owners, access policies, approval expectations, and token or licensing controls rather than treating them as interchangeable tools.

Back to TOC

A practical 30 day governance roadmap

Days 1 through 5: name an executive sponsor, operational owner, technical administrator, inquiry owners, and security reviewer. Confirm the target version and entitlement. Inventory candidate inquiries and classify their data. Days 6 through 10: choose five to ten high-value questions, review inquiry exposure and descriptions, and build a role matrix. Days 11 through 15: process descriptions, assign pilot roles, test non-administrator access, and define consumption thresholds and support routing.

Days 16 through 22: run the controlled pilot, reconcile answers, capture feedback, and correct inquiry design rather than asking users to work around bad results. Days 23 through 30: review usage, evidence, access results, and unresolved risks. Decide whether to expand to another audience, add a small set of inquiries, improve training, or pause until a control is strengthened. Repeat the cycle whenever material data, roles, or release conditions change.

Back to TOC

Common rollout mistakes to avoid

The first mistake is exposing broad inquiries because they are already available to an administrator. The second is assuming inherited access means no review of inquiry scope is necessary. The third is measuring only demonstrations and not reconciliation quality. Other frequent problems include failing to explain parameters, neglecting AI Unit thresholds, allowing a pilot to become a silent production rollout, and using AI output as a substitute for a controlled approval or financial review.

A more reliable approach is intentionally modest: a limited question set, a small user group, named owners, tested roles, and evidence that results match trusted sources. That discipline makes expansion easier because every new inquiry and audience has a clear route through the same governance process.

Back to TOC

Conclusion and next step

Acumatica AI Assistant can make governed ERP information easier to reach, but it does not create governance by itself. The organization creates it by curating Generic Inquiries, assigning roles deliberately, monitoring AI Units, testing answers, and keeping people accountable for decisions. The strongest rollout is one where users can explain what the assistant can use, why they can see the answer, and how they would verify it.

Begin with a short AI reporting and security workshop: select the initial business questions, review the underlying inquiries and access model, define pilot success measures, and document the owner for each control. Biz-Tech Services can help organizations assess reporting design, Generic Inquiry exposure, security roles, custom development, and the practical path from pilot evidence to an operational rollout.

Back to TOC

Frequently Asked Questions

Is Acumatica AI Assistant generally available in 2026 R2?

Acumatica states that, as of the 2026 R2 release, the managed-availability program concluded and AI Assistant is generally available to customers on 2026 R1 and later. Confirm entitlement and configuration for the target tenant before rollout.

What data can AI Assistant use?

It works through Generic Inquiries that an administrator has configured and exposed to AI Assistant. The organization should maintain an inventory of those inquiries and review their purpose, scope, and ownership.

Does AI Assistant respect Acumatica security?

Acumatica says it inherits access rights defined on each Generic Inquiry. Organizations should still test actual role combinations with non-administrator pilot accounts and review the inquiry scope itself.

Can AI Assistant change ERP records?

The official FAQ describes it as limited to querying configured Generic Inquiries; it cannot perform actions or update records.

What are AI Units?

AI Units measure AI Assistant consumption. Monitor them in the AI Unit Consumption screen and License Monitoring Console, set thresholds, and plan for the possibility that the monthly allocation may be exhausted.

Why do Generic Inquiry descriptions matter?

Descriptions help the assistant interpret business language and parameters. They should define measures and constraints clearly without storing sensitive information that does not belong in a description.

How is Biz Tech AI Analyst different?

Biz-Tech AI Analyst is a separate customization that proposes and, after user approval, creates or changes reports and Generic Inquiries within a user’s rights. It does not change business data.

What is the safest first rollout?

Start with a small pilot of high-value, reconcilable questions; validate roles, exposed inquiries, usage, and user understanding before expanding.

Back to TOC

Sources

• Acumatica AI Assistant FAQ
• Exposing Generic Inquiries to AI Assistant
• Working with AI Assistant general information
• Acumatica artificial intelligence overview
• Acumatica on AI ERP evaluation and governed access
• Biz Tech AI Analyst product documentation — Internal Biz-Tech product documentation, September 2026

Back to TOC

---

by Gary