# Epicor BAQ Performance Tuning Checklist: Fix Slow Queries and Dashboards > Source: https://netray.co/tools/epicor-baq-performance-tuning-checklist > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Free Tools ## Short answer Work through a practical list of checks when a BAQ, dashboard or BPM lookup runs slowly in Epicor Kinetic. ## Category epicor ## Erp Epicor Kinetic ## Audience - BAQ developer - Epicor admin - DBA ## Tool **Kind:** checklist **Scoring Note:** Critical items usually explain the largest share of slowness. Fix those first, then re-test with the same parameters. **Groups:** #### Reproduce and measure **Items:** **Text:** Run the BAQ with the same parameters that are slow for the user **Critical:** true **Text:** Record the run time and row count before changing anything **Critical:** true Check whether the slowness is the query or the dashboard rendering and grid Test as a user with the same security group, not only as admin Note whether the issue is constant or only at certain times of day #### Joins and tables **Items:** **Text:** Every join includes Company and all key columns of the parent table **Critical:** true Remove tables that are joined but contribute no output or criteria Use inner joins where a match is always required instead of outer joins Avoid joining the same large table twice if a subquery or one pass would do **Text:** Check that Customer and Vendor joins use CustNum and VendorNum **Critical:** true #### Criteria and filters **Items:** **Text:** Large tables such as PartTran, LaborDtl and InvcDtl have a date or key filter **Critical:** true Filters sit in table criteria rather than in post-query display filters Use parameters with sensible defaults so users do not run unbounded queries Avoid LIKE with a leading wildcard on large tables Avoid functions on filtered columns that stop an index from being used #### Calculated fields and subqueries **Items:** Heavy calculated fields are not evaluated per row where a join would do **Text:** Correlated subqueries are replaced by joins or pre-aggregated subqueries **Critical:** true Subqueries return only the columns needed Return only the columns the dashboard displays Avoid distinct or sorting on large result sets unless needed #### Database and environment **Items:** **Text:** Ask the DBA whether index and statistics maintenance ran recently **Critical:** true Check for blocking or long-running sessions during the slow period Compare against a test environment with similar data volume Review execution plan for table scans on large tables Confirm the BAQ is not called repeatedly by a BPM or a refresh timer After changes, retest and document the before and after times ## Content **Intro:** Slow BAQs and dashboards are one of the most common complaints from Epicor users. Most slowness comes from a handful of causes: loose joins, unbounded date ranges on big tables and repeated calls. Use this checklist in order. **Sections:** #### How to use the checklist **Body:** Start with the measurement group so you know the baseline. Then work down: joins, criteria, calculated fields and finally the database. Change one thing at a time and re-run with the same parameters, so you can tell which change helped. Export the checked list and attach it to the support ticket or change record so the next developer knows what was tried. #### The usual suspects **Body:** On most systems the same three issues explain the majority of slow queries. First, a missing Company or key column in a join that multiplies rows. Second, no date filter on a history table, so the query reads years of transactions. Third, a correlated subquery that runs once per row. Fix those and you will often see a ten times or better improvement without touching indexes. **Bullets:** - Check join keys before anything else - Bound history tables by date - Replace per-row subqueries with joins #### When it is not the query **Body:** If the query runs fast in the BAQ designer but the dashboard is slow, the cause is probably the grid, too many columns or a refresh timer. If it is slow only at certain hours, look for competing jobs such as MRP, backups or other reports. Heavy analytics belong on a replica or data warehouse rather than the live transactional database, which protects shop floor transactions. **Cta:** If your users export Epicor data to spreadsheets because dashboards are too slow, Netray can help set up a read-only analytics layer off your live system. **Faq:** #### Why is my BAQ fast in the designer but slow on a dashboard? **Answer:** The designer usually tests a limited number of rows. Dashboards may run the full set, add grid rendering and refresh on a timer. Reduce returned columns, add parameters and check refresh settings. #### Do I need to add indexes? **Answer:** Only after fixing joins and filters. Standard tables are indexed for key access. Custom indexes should be agreed with your DBA and Epicor support, because they can be overwritten or affect upgrades. #### Does Epicor cache BAQ results? **Answer:** Some data is cached on the client side, but you should not rely on caching for performance. Make the query efficient and bounded by parameters. #### How can I find which BAQs are slow? **Answer:** Use Epicor's server logging and tracing options, or ask the DBA to review long-running queries on the database. Then trace the offending query back to its BAQ by its text and tables. ## Search terms epicor slow baq, epicor baq performance, epicor dashboard slow, epicor baq tuning, epicor query optimization, epicor baq best practices --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json