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
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:
- The inquiry returns quickly enough for its operational purpose.
- 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.
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.
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.
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:
- Does the base inquiry return fewer rows or perform fewer calculations after the change?
- Does the grouped view merely collapse rows visually, or does it change the data request?
- Are the same filters and parameters applied in both the baseline and revised tests?
- 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.
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.
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.
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.
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:
- Mark the parent business entity that defines one intended row.
- List every output field and identify its source.
- List every condition, parameter, formula, grouping field, and navigation field.
- Remove fields that no consumer uses.
- Identify data sources that remain only because of removed fields.
- 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.
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.
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.
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.
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.
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.
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.
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:
- Select a base inquiry with a documented grain and validated totals.
- Choose the first group that matches the user’s primary decision, such as vendor, customer, warehouse, project, or branch.
- Add a second group only when it supports a common drill path, such as financial period within vendor.
- Select aggregate fields that reconcile to the base inquiry.
- Choose a meaningful sort within each group.
- Decide which groups open expanded or collapsed based on typical result size.
- Show only fields needed at each level.
- 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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
- Copy or export the current inquiry and dependent views before modification.
- Record the inquiry identifier, site map location, access rights, and consumers.
- Make and test the change in a nonproduction environment with representative data.
- Run functional, reconciliation, performance, and security tests.
- Review dependent dashboards, pivot tables, grouped views, OData consumers, and nested inquiries.
- Schedule the release when rollback and observation are practical.
- Recheck parameters, filters, roles, shared views, and default views after deployment.
- 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.
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.
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.
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.
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.
Sources
- Acumatica 2026 R2 Reporting Tools Guide
- Creation of a Generic Inquiry General Information
- Generic Inquiry Form Reference SM208000
- Data Views General Information
- Data Views Creating and Configuring Grouped Tables
- Modification of Inquiry Results The Number of Records Shown
- Data from Multiple Data Sources General Information
- Data from Multiple Data Sources Discovery of Key Fields
- Sorting and Grouping General Information
- Widget Settings General Information
- Specific Widgets Table Widgets
- 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.
