Clear Cutover Get a quote

Epicor Kinetic · Start here

The Epicor Kinetic report and customization backlog: a practical guide to clearing it, and keeping it clear

Applies to: Epicor Kinetic and Epicor ERP 10.2 reporting and customization environments. Menu paths, developer tools, and operational capabilities vary across minor releases, deployment models (SaaS Cloud vs. On-Premises/Hosted), and security group permissions. Always validate architectural workflows in a dedicated pilot or staging environment before modifying production.

In short

ERP reporting and customization backlogs expand when technical teams treat incoming operational requests as net-new development tasks before validating the underlying business requirements. A sustainable clearing cadence starts by confirming operational necessity, leveraging standard out-of-the-box functionality, matching the requirement to the correct technical delivery layer, and enforcing testable acceptance criteria prior to sprint commitment.

Substantial ticket volume can be closed without writing code: users frequently require guidance with an existing standard Tracker, a personalized grid layout, an out-of-the-box business dashboard, or an existing Report Style. When custom development is genuinely required, technical debt is minimized by selecting the appropriate framework — whether a Business Activity Query (BAQ), Report Data Definition (RDD) and SSRS layout, an Application Studio layer, a Business Process Management (BPM) directive, an Epicor Function, or a REST API integration.

For organizations managing Classic Smart Client to Kinetic UX transitions, avoid 1:1 screen-for-screen rebuilds. Establish an accurate customization inventory, verify active business utilization, map functional overlap against standard Kinetic enhancements, and systematically classify each artifact to retire, configure, convert, or architecturally redesign.

The seven backlog ticket archetypes

Enterprise support queues typically contain requests spanning seven recurring patterns. Applying targeted triage protocols prevents premature development and maintains architectural consistency:

1. The "Excel dump" operational Data request

Symptom: Users request custom SQL or SSRS reports (e.g., open job operations, scrap variances, purchase receipts) simply to export raw data into Excel for ad-hoc filtering and pivot tables.

Triage Protocol: Demonstrate existing standard Trackers (e.g., Job Tracker, Part Tracker) or standard system queries first. If users require an operational, recurring tabular dataset with custom columns, deploy an optimized BAQ exposed via an Application Studio grid or Kinetic dashboard. Reserve SSRS specifically for formal, paginated, customer-facing, or controlled document printing.

2. The missing document field

Symptom: A customer-facing business document (Order Acknowledgement, AR Invoice, Purchase Order, Packing Slip) lacks a required field, such as a customer PO line reference, revision note, or tracking number.

Triage Protocol: Inspect Report Style Maintenance to verify whether the report is powered by a Report Data Definition (RDD) or a BAQ. Locate the source table in the RDD to confirm if the field is present but marked as excluded, or if the table itself must be linked. Never assume an added field is strictly an SSRS Report Definition Language (RDL) layout tweak — data definition, dataset query syntax, and report design must stay synchronized.

3. Classic-to-Kinetic upgrade debt

Symptom: Legacy Epicor ERP 10.2 / Classic Smart Client forms containing embedded C# WinForms client scripts, personalizations, or direct object calls fail to execute or behave inconsistently in the Kinetic browser UI.

Triage Protocol: Inventory legacy customizations, verify active usage via process owners or telemetry (such as the Activity Tracker where available), and evaluate modern Kinetic baseline capabilities. Retire obsolete modifications; convert supported presentation layouts into Application Studio layers; and refactor procedural business logic into Epicor Functions or server-side BPM directives.

4. Stuck, hanging, or timed-out reports

Symptom: Critical reporting tasks remain in active or pending states indefinitely, or fail under large data ranges.

Triage Protocol: Capture precise execution timing and inspect System Monitor. Check whether the failure is global or isolated to a specific definition. In on-premises environments, cross-reference Windows Event Viewer logs if the Task Agent service state desynchronizes; in SaaS deployments, review available execution history or submit a cloud support request. One practical recovery pattern when a task is stalled in System Monitor is to cancel it—which inserts an Ice.SysTaskKill record—and then restart the Task Agent service so the task can be cleaned up and moved to history. Verify this behavior on your specific release. Under no circumstances should administrators manually edit or delete task records directly in the SQL database.

5. BPM directives failing post-update

Symptom: Method Directives or Data Directives trigger unhandled server exceptions or execution loops following a minor or major Kinetic update.

Triage Protocol: Capture the complete server call stack, isolate whether a Method Directive (tied to a specific service contract) or Data Directive (triggered on table-level write operations, including Data Migration Tool imports) is responsible, and replicate the failure in a dedicated pilot instance. Verify null handling and schema changes, make minimal supported corrections, and run comprehensive end-to-end regression tests.

6. The vague "quick tweak"

Symptom: High-level requests such as "streamline shipping entries" or "automate PO release checks" that lack operational boundaries.

Triage Protocol: Enforce the Eight-Point Change Intake Template. Require requesters to document business impact, trigger conditions, exceptions, and test criteria. Retain tickets in clarification until specifications are testable.

7. Abandoned or ghost requests

Symptom: Aging tickets lingering in the queue where the initial submitter has departed, adopted an unapproved workaround, or no longer experiences the problem.

Triage Protocol: Execute a periodic review. Issue a formal closure notice requiring re-validation within a defined window. If unconfirmed, close the ticket as abandoned with an audit trail, permitting reopening only with complete test scenarios. Never close compliance, financial-control, or safety-critical tickets purely due to age.

Architectural delivery Layer selection

To prevent performance degradation and technical debt, align every technical request with its appropriate architectural tier:

Requirement Category Primary Architectural Tier Secondary / Alternative Tier
Internal Operational List (Interactive filtering, column sorting, Excel export) Standard Kinetic Tracker, built-in system query, or a BAQ-backed grid in Application Studio. SSRS only when rigid, multi-page paginated print controls are legally or operationally required.
Customer/Vendor Document (Invoices, Pack Slips, POs, BOLs) Existing standard Report Style and Report Data Definition (RDD). Duplicated/Custom RDD with extended RDL layout when fields or styling must be customized.
Screen Layout & UI Interaction (Field order, required UI highlights, panel visibility) Application Studio Layer (custom layer assigned via Menu Maintenance) or user Personalization. Server-side validation if the underlying business rule must be enforced across all client touchpoints.
Global Enterprise Business Rules (Validations across screens, DMT, and REST calls) Server-side Method Directive or Data Directive (BPM). Epicor Functions (EFx) when reusable, modular, procedural business logic is required across services.
Cross-System / Multi-Year Analytics (Historical trend reporting, enterprise dashboards) Enterprise Analytics / BI Platform (e.g., Power BI, external data warehouse). Direct BAQ execution if record volume, table joins, and database impact remain within safe boundaries.

Managing Classic-to-Kinetic upgrade debt

The transition from legacy Classic Smart Client (WinForms) to the modern Kinetic web framework represents an architectural paradigm shift. Client-side C# scripts, custom DLL assemblies, and form modifications built on legacy .NET controls do not execute in the browser client.

  • Vendor Lifecycle Milestones: Epicor's official feature sunset announcement designated release 2026.1 (May 2026) as the retirement date for the Kinetic Smart Client (classic forms). For organizations operating on or upgrading to 2026.1 and later, legacy WinForms customizations cannot execute, making conversion to the browser UX an operational requirement.
  • Application Studio vs. Classic C#: Classic UI code relied on WinForms event hooks; Kinetic Application Studio uses declarative JSON-based layers, event definitions, data views, and component properties. Rebuilding legacy code requires translating procedural UI scripts into Application Studio event workflows or migrating the logic server-side.
  • Telemetry & Audit: Before scheduling development sprints, audit legacy customization menus. Where available in your Kinetic release, check the Activity Tracker or system usage logs to verify whether custom dashboards and screens are actively utilized by end users.
  • Runtime Debugging: When diagnosing screen performance or event execution delays in Kinetic UX, developers can leverage browser developer tools: press F12, click within the Kinetic form workspace, and press Ctrl + Alt + 8 to toggle verbose diagnostic debug logging in the browser console.

Modifying shipped SSRS reports: Standard workflow & cautions

Altering base system reports requires strict adherence to Epicor's data definition and styling hierarchy to avoid unrecoverable report failures:

  1. Identify Report Architecture: In Report Style Maintenance, inspect the report style to confirm whether it is driven by a Report Data Definition (RDD) or a Business Activity Query (BAQ Report) before attempting modifications, as the development path and designer tools differ completely between the two.
  1. Duplicate the RDD: Never attempt to modify an out-of-the-box system RDD directly. Use Actions > Duplicate Report within Report Data Definition to produce a company-specific copy.
  1. Include Necessary Fields: Within the duplicated RDD, link the requisite tables or uncheck the Excluded flag on required fields. Fields flagged as excluded are entirely omitted from the extracted XML/SQL staging dataset.
  1. Create a Custom Report Style: In Report Style Maintenance, copy the base style, rename it clearly, and point the definition to your duplicated RDD. Verify the relative report path points to your custom SSRS folder.
  1. Update RDL Dataset Query: In SQL Server Report Builder or Visual Studio, open the custom .rdl file. Add the newly exposed database fields to the RDL query statement and the report dataset field collection before placing them onto the canvas layout.
  1. The "Sync Dataset" Caution: Be cautious when using the Sync Dataset action in Report Style Maintenance on customized reports. Syncing can overwrite custom query expressions, groupings, or parameters previously added to the RDL. While some developers report successful synchronization on simple custom reports, always keep a version-controlled backup of your .rdl file and test on a copy first.

The four-stage backlog triage workflow

  1. Stage 1: Inactivity Purge Identify tickets inactive for greater than 60 days. Dispatch a standardized audit notice:

"We are auditing the ERP enhancement queue. Please confirm if ticket [ID] remains an active operational bottleneck and supply documented test scenarios by [Date]. Without confirmation, this request will be archived."

  1. Stage 2: Standard Capability Audit Determine if core ERP functionality, modern Trackers, or standard application grids satisfy the requirement without code. Conduct an interactive user walk-through before marking as resolved.
  1. Stage 3: Architectural Layer Alignment Select the least complex, most upgrade-resilient technology tier (refer to the Architectural Delivery Layer table).
  1. Stage 4: Scope Enforcement Require full completion of the intake template before assigning development resources. Incomplete requests remain in pending clarification.

The Eight-Point Change-request intake template

Technical development cannot commence without documented completion of these eight specifications:

  1. Business Problem: Concrete operational delay, financial exposure, or compliance risk being addressed.
  1. Target Artifact: Precise screen ID, menu path, report style, or business object contract involved.
  1. Data Elements: Business label and verified database schema names (Table.Field).
  1. Trigger Conditions: Exact transactional lifecycle event (e.g., On Line Release, Pre-Update).
  1. Business Rules & Edge Cases: Logical validation conditions, system error behavior, and missing-data handling.
  1. Audience & Security Scopes: Affected site IDs, user roles, security groups, and company boundaries.
  1. Visual Mockup / Output Spec: Annotated screenshot, sample spreadsheet, or target layout draft.
  1. Acceptance Test Scenario: Step-by-step transaction walkthrough, expected outcomes, and designated pilot sign-off owner.

Operational cadence & backlog Maintenance

  • Weekly Operational Review: Assess newly submitted requests, unblock tickets lingering in technical clarification, and triage emergency production fixes.
  • Monthly Systems Retrospective: Review stale items, verify ownership, and identify systemic end-user training gaps driving duplicate reporting requests.
  • Pre-Upgrade Regression Audit: Prior to deploying major Kinetic releases or cloud updates, cross-audit all active RDDs, custom SSRS layouts, Application Studio layers, BPM directives, and Epicor Functions against pilot sandbox environments.
  • Closure Taxonomy: Classify every completed ticket into standard categories (Standard Training, Grid Configuration, BAQ/Report, Server Logic/BPM, Archived/Obsolete) to maintain strategic visibility into ERP customization drivers.

FAQ

Why do ERP reporting requests proliferate so rapidly?

Operational users frequently encounter information gaps and immediately request custom reports, unaware that standard Trackers or system dashboards contain the necessary data. Establishing structured intake, coaching users on standard search capabilities, and supplying reusable BAQs significantly curbs avoidable backlog accumulation.

Must every legacy Classic screen customization be rebuilt in Application Studio?

No. Thoroughly assess whether modern out-of-the-box Kinetic features have rendered the legacy customization redundant. Rebuild only modifications that deliver validated, active business value.

Why do SSRS reports occasionally fail following a Kinetic release update?

Core database schema updates, deprecated fields within system RDDs, or modified database query views can break custom RDL queries. Maintaining strict isolation of custom RDD copies and incorporating report suites into pre-release pilot testing mitigates post-update failures.

References

Procedures should always be cross-referenced against official Epicor documentation matching your specific release and hosting architecture:

  • Application Studio Architecture: Epicor Kinetic Application Studio Overview
  • Server-Side Logic: Epicor Functions Framework
  • Modernization Education: Epicor: Upgrading Classic Customizations to Kinetic UX (Curriculum Overview)
  • Knowledge on Demand: Converting Kinetic Personalizations into Customizations (Epicor Video) Adding an Application Studio Layer to the Menu (Epicor Video)
  • Classic Sunset Roadmap Announcements: Epicor Feature Sunset Announcement: Classic Forms Sunset at 2026.1 EpiUsers: Classic Sunset Officially at 2026.1 2W Tech: Epicor 2026.1 Ends Classic Screen Support
  • Custom Report Workflows & Sync Dataset Analysis: EpiUsers: Custom Reports (RDD vs BAQ Reports) EpiUsers: The Truth About Report Style "Synch Dataset" EpiUsers: Importing a Field to SSRS Report
  • Task Agent & Diagnostics: EpiUsers: Clearing Stuck Reports in System Monitor EpiUsers: Kinetic Browser Debugging Shortcuts

Systems I work on