# Epicor Application Studio: understanding customization layers > Source: https://netray.co/erp-help/epicor-application-studio-layers-explained > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## 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. ## Kind advanced ## System epicor ## Erp Epicor Kinetic ## Module Customization / Application Studio ## Query epicor application studio layers explained ## Alternate Queries - epicor kinetic customization layer vs personalization - application studio base layer extended layer - epicor kinetic ui customization not showing ## 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. ## Steps ### Diagnose which layer is winning **Items:** Open the screen in Application Studio: Customization > Application Studio, open the layer you intend to edit from the Layer dropdown at the top. Check the Layer dropdown itself - it lists Base, any Customization layers, and Personalization; confirm you are editing the layer you think you are. Use View > Show Layer Info (or hover the control's properties panel) to see which layer currently owns a given control's visible property values. If 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. Check 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. For 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. Republish and do a hard refresh (clear Kinetic client cache / new browser session) - stale cached layer definitions are a common false negative. ## Sections ### The four-layer model **Body:** 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 **Body:** 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 **Body:** 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. ## 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. ## Ai Angle 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. ## Faq ### Can I have more than one Customization layer active on the same screen? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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. ## Search terms epicor application studio layers, epicor kinetic customization vs personalization, epicor base layer customization layer, epicor extended layer, application studio deployment scope, kinetic customization not showing, epicor layer info --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json