Epicor Application Studio: understanding customization layers
epicor application studio layers explained
Also searched as
- epicor kinetic customization layer vs personalization
- application studio base layer extended layer
- epicor kinetic ui customization not showing
Short answer
Kinetic UI is built in layers loaded in order - Base (Epicor-delivered), Customization (Application Studio, company/layer-wide), Personalization (user- or role-specific, applied on top), and optionally Extended (packaged add-on layers) - and a change you make will not appear if a higher layer overrides the same control or if you are testing in the wrong layer context.
Applies to: Epicor Kinetic 2021.1 and later Kinetic UI (Application Studio); does not apply to classic Epicor 10 Menu-driven forms which use a different customization model.
Diagnose which layer is winning
- 1Open the screen in Application Studio: Customization > Application Studio, open the layer you intend to edit from the Layer dropdown at the top.
- 2Check the Layer dropdown itself - it lists Base, any Customization layers, and Personalization; confirm you are editing the layer you think you are.
- 3Use View > Show Layer Info (or hover the control's properties panel) to see which layer currently owns a given control's visible property values.
- 4If a customization layer is not appearing at runtime, confirm it is Published (not just saved as draft) and assigned to the correct company/site/user group under Deployment.
- 5Check for a Personalization on top: end users or roles can personalize individual fields (hide/show/rename) which overrides your customization layer for that user - ask the user to clear personalization or check Tools > Personalization from the Kinetic client.
- 6For Extended (packaged) layers from ISVs or prior consultants, list active layers under System Setup > Customization Maintenance and confirm load order - later layers in the stack can override earlier ones for the same control.
- 7Republish and do a hard refresh (clear Kinetic client cache / new browser session) - stale cached layer definitions are a common false negative.
The four-layer model
Base is the out-of-box Epicor-delivered screen definition - never edit this directly since it is overwritten on upgrade. Customization is what you build in Application Studio: it is saved as a distinct layer tied to a screen, versioned, and deployable to specific companies or user groups without touching Base.
Personalization sits above Customization and is end-user or role-scoped - a user can hide a column or rename a label for themselves via the Kinetic client's personalization mode, and that persists per-user regardless of what the customization layer says, which is the single most common reason "my customization isn't showing."
Extended layers (sometimes called packaged customizations) are customization layers delivered as installable packages, often from an ISV add-on or a prior implementation partner - they load in a defined order alongside your own customization layer, and two layers editing the same control's same property will conflict, with the later-loaded layer typically winning.
Deploying and scoping a layer
When you save a customization in Application Studio, you choose a Layer name and deploy scope - company, site, or specific user/role assignment. A layer with no deployment assigned exists but never loads for anyone, which is a frequent gotcha after building a customization and testing only in the designer's preview (which always shows the layer regardless of deployment).
Multi-company Epicor environments need the layer explicitly deployed per company; a layer built and tested in company 100 will not automatically appear in company 200 without adding that deployment.
Extended layers and upgrade risk
Because Customization layers are separate from Base, Epicor version upgrades generally preserve your customization layer, but if the Base screen's underlying control structure changes significantly (a field renamed or moved to a different panel), a Customization layer referencing the old control can break silently - re-test all customized screens after any Kinetic version upgrade.
Layer conflicts between multiple customization layers (e.g. one from an in-house build, one from an ISV package) are best avoided by consolidating logic into one layer where possible, or by clearly documenting which layer owns which control to avoid two teams fighting over the same field.
Common pitfalls
- !Editing and testing only inside Application Studio's own preview, which always renders the layer, then wondering why end users in the live Kinetic client do not see the change because deployment scope was never set.
- !Assuming a hidden field is hidden for everyone when it is actually an individual user's Personalization, not the shared Customization layer.
- !Two customization layers modifying the same panel with conflicting layout changes, producing unpredictable rendering order at runtime.
- !Forgetting that classic Epicor 10 form customizations and Kinetic Application Studio layers are not the same technology - a classic customization does not carry over automatically to the Kinetic UI equivalent screen.
- !Not republishing after an edit - Application Studio has a distinct Save vs Publish action and only published layers are live.
- !Browser or client-side caching showing a stale layer version after publish; a full logout/login or cache clear is often needed to confirm.
How an ERP-grounded AI assistant handles this
An AI assistant grounded in a specific Epicor tenant's customization export can answer "why isn't my field hidden" by actually diffing the Base, Customization, and known Personalization states for that screen and control, rather than a generic answer about layers - useful when a company has years of accumulated ISV-packaged layers nobody fully documented.
Frequently asked questions
Can I have more than one Customization layer active on the same screen?
Yes, Epicor supports multiple customization layers per screen, loaded in a defined order, but overlapping edits to the same control are a common source of confusing behavior - Epicor recommends consolidating related changes into a single layer per screen where practical.
Does Personalization survive a Kinetic upgrade?
Personalizations are stored per-user in the database, separate from the customization layer's package, so they typically survive upgrades, but if the underlying control they reference is removed or renamed in Base, the personalization can no longer apply and silently drops.
How do I remove an old ISV-packaged extended layer cleanly?
Go to Customization Maintenance, identify the layer's exact name and scope, and unassign its deployment before deleting - removing it without checking dependent BPMs or dashboards that reference controls it added can break those artifacts.
Is there a way to see all layers affecting one screen at once?
Application Studio's layer info view and the Customization Maintenance list together show what is deployed where, but Epicor does not provide a single unified "effective layer" diff view - for complex stacks, exporting each layer's definition and comparing is the practical approach.
Related
How to create and call an Epicor Function
Open Function Studio from the main menu (Customization > Function Studio) or from inside a BPM designer's Call Context widget, define a Library and Function with typed inputs/outputs, write the logic in the C# widget, then compile and test with the built-in test harness before calling it from a BPM directive, a dashboard, or another function.
How-toPreserving Customizations When Upgrading to Epicor Kinetic
Epicor Kinetic's web UI does not simply inherit classic smart-client customizations - most need to go through the Update Customization / Application Studio conversion process, and some WinForms-specific customizations cannot convert directly and must be rebuilt in the Kinetic designer. Plan the upgrade as a customization inventory and rework project, not a single technical cutover step.
How-toHow to build a Kinetic homepage dashboard in Epicor
Kinetic homepage dashboards are built from Active Homepage Maintenance: create a BAQ that returns the metric or list you want, add a KPI or List widget referencing that BAQ, arrange widgets on the homepage layout, and assign the homepage to a role or company so the right users see it.
Error fixFixing Epicor BusinessObjectException: BPM Directive Errors
A BusinessObjectException that says "A Business Process Management (BPM) directive has raised the following error" means a directive on that business object stopped the transaction, either deliberately via a Raise Exception widget or accidentally via an unhandled .NET error in Custom Code. Expand the InnerException on the error dialog to see the real message and the directive name, then open BPM Designer for that object and method to find the widget that fired.
How-toFixing a Slow Epicor BAQ (Business Activity Query)
A slow BAQ in Epicor is usually caused by unindexed join columns, a subquery or calculated field forcing a table scan, or the BAQ pulling far more rows than the dashboard actually displays before filtering client-side. Fix it by reading the SQL Server execution plan Epicor generates, moving filters into the BAQ criteria instead of the dashboard filter panel, and replacing subqueries with joins where possible.
How-toEpicor MRP Runs but Generates No Suggestions
When Epicor's MRP process completes without a job or purchase suggestion for a part you expect one for, the cause is almost always the part's own configuration (Part Class Type, Make Direct, Non-MRP flag, planning Time Fence) or the demand not being linked in a way MRP recognizes, not a defect in the MRP engine. Work through the part's Planning tab, its safety stock and lead time setup, and the demand source (sales order line status, job material requirement) before assuming the run itself failed.
AI for ERPAI for Epicor Kinetic, Beyond What Prism Covers
Add AI to Epicor Kinetic beyond Prism: private LLM over BAQs, BPM data, and REST v2, on-prem or private cloud, with honest guidance on when Prism already covers you.
Stuck on Epicor Kinetic?
Talk to engineers who work inside Epicor Kinetic every week, and who build private AI that answers these questions from your own ERP data.