Epicor Kinetic Personalization vs Customization Explained

Short answer

In Epicor Kinetic, a personalization is a change one user makes to how a screen looks for themselves. A customization is a change built in Application Studio, published as a layer, and attached to a menu item (or process call) for a defined group of users or everyone. Both sit on top of Epicor's standard screen, so the base screen definition is not overwritten.

Key facts

Personalization = for one user, limited to presentation and layout preferences.
Customization = built and published in Application Studio, then linked to a menu item in Menu Maintenance (or Process Calling Maintenance) for many users.
Application Studio applies to the Kinetic browser interface only. It does not change Classic Smart Client screens.
Classic C# WinForms scripts do not run in the Kinetic browser interface.
A UI change is not a business rule. Rules that must always be enforced belong in server-side logic (BPM or Epicor Functions).

Side-by-side comparison

	Personalization	Customization
Who makes it	An individual user	A developer or administrator
Who sees it	Only that user	Users who open the menu item (or process call) where the published layer is attached
Tool	Kinetic screen personalization	Application Studio + Menu Maintenance
Typical changes	Show or hide fields, change grid column order, widths, filters, and density	Everything a personalization does, plus events, rules, data views, and new controls
Needs permission	Yes (Personalization privilege)	Yes (Application Studio / Security Manager privileges)
Good for	"I want my screen to look like this."	"Our shipping team needs this screen to work this way."

The exact options available to each depend on your release and permissions.

What is a layer and how does the runtime stack work?

A layer is a saved set of JSON metadata changes (deltas) that sits on top of a standard Epicor Kinetic screen. The standard base screen stays intact underneath.

When a user opens a screen in the Kinetic browser interface, Epicor merges changes in a three-tier stack:

Base Application (Epicor's standard screen)
Published Customization Layer (loaded from the Menu Maintenance item or Process Calling rule)
User Personalization (the individual user's saved view preferences, applied last)

Because a user's personalization is applied on top of the customization layer, an old personalization can sometimes hide or conflict with a newly published Application Studio change. If a single user reports that a newly deployed customization looks broken on their screen, clearing their saved personalization in Personalization Purge returns them cleanly to the published customization layer.

Which one should I use?

Use this simple decision path:

Only one person wants the change. Use a personalization.

A team, role, or whole site needs the same change. Build and publish a customization layer in Application Studio, then attach that layer to the target menu item in Menu Maintenance (controlled by a Security ID) or register it in Process Calling Maintenance if the screen is launched from context menus or slide-out panels.

A rule must always be enforced, no matter which screen, import, or API call the data comes through. Do not rely on the screen. Use server-side logic such as a BPM directive or an Epicor Function.

People only need data in a list. Consider a BAQ shown in a grid or dashboard before changing a standard screen.

A personalization is turning out to be useful to many people. Epicor provides a Convert Personalization to Layer option in Application Studio. Import the user's personalization into Application Studio as a new layer, publish it, and assign it in Menu Maintenance so the change is documented, owned, and managed centrally rather than recreated by hand from user to user.

Common mistakes

Treating a hidden field as security. Hiding a field on a screen only changes what appears on that screen. The data may still be visible elsewhere, such as in another screen, a report, a BAQ, or through the API. Use Epicor Field Security, BAQ/Service Security, and server-side controls to protect sensitive data.

Expecting Classic scripts to work. Classic customizations used C# code and WinForms controls. These do not execute in the Kinetic browser interface. Inventory old customizations, confirm which are still used, and rebuild only what has real business value.

Using the screen to enforce business rules. A screen-level check can be bypassed by other entry points such as DMT imports, REST API calls, and other screens. Put important validations on the server.

Leaving layers undocumented. Record the layer name, the base app it affects, the Menu IDs or Process Calling rules where it is attached, the purpose, the owner, and the date. Without this, nobody knows what is safe to remove.

Skipping testing after an update. Layers refer to components and events on the standard screen. When a release changes those parts, a layer may behave differently. Open every customized screen in a pilot environment after an update before it reaches production.

A simple layer naming and documentation habit

Use a clear prefix and naming convention that includes the company/team and purpose.
Keep a simple register (a spreadsheet is enough) listing every customization layer, its base application ID, the Menu IDs where it is used, its owner, and its purpose.
Review the register on a set schedule and retire layers nobody uses.

FAQ

What is the difference between personalization and customization in Epicor Kinetic?

A personalization is a change an individual user makes for their own view of a screen. A customization is built and published in Application Studio and attached to a menu item (or process call) so a group of users sees it.

Does a personalization affect other users?

No. A personalization applies only to the user who made it, though it sits on top of any customization layer assigned to that screen and can occasionally conflict with new customization changes until cleared via Personalization Purge.

Does a customization change Epicor's standard code?

No. It is stored as a separate metadata layer on top of the standard screen.

What is Application Studio?

It is the Kinetic design tool used to build customizations for the browser interface, using layers, events, rules, data views, and component properties rather than Classic C# WinForms code.

Will my customizations survive an upgrade?

Layers are kept separate from the base screen, which reduces upgrade friction, but they must still be tested after each update because the base screen components and events they reference can change.

Can I use my old Classic customizations in Kinetic?

Not directly. Classic C# WinForms code does not run in the Kinetic browser interface. Review each one and retire it, replace it with standard functionality, rebuild the UI changes in Application Studio, or move the business logic to a server-side BPM or Epicor Function.

Does Application Studio change the Classic Smart Client?

No. It applies to the Kinetic browser interface.

Who should be allowed to customize screens?

A small, trained group. Treat Application Studio access like development privileges, with testing in a pilot environment and change approval before publishing layers to production menus.

References

Cross-check against official Epicor documentation matching your release and hosting model:

Epicor Kinetic help: Application Studio Overview
Epicor Kinetic help: Menu Maintenance and Process Calling Maintenance
Epicor Knowledge on Demand: Converting Kinetic Personalizations into Customizations (video)
Epicor Knowledge on Demand: Adding an Application Studio Layer to the Menu (video)
Epicor: Upgrading Classic Customizations to Kinetic UX (curriculum overview)