I’m pretty new to customizations, and normally if I need to customize a screen there is almost already a customization. Not sure if it’s a bad thing almost all of our screens are customized… Anyway I customized a screen today and there were no customizations so I had to create a new customization. There were two unrelated changes I wanted to make and in thinking about what to name the customization I realized it seemed like bad design to have 1 customization with multiple unrelated customizations. So as an example the first customization was to unlink all checkboxes from the labels as if users click the label it toggles the checkbox(internally known as the “checkbox bug” and there is quite a bit of angst…) the second change was to add a couple UD fields. The design concept of “separation of concerns” tells me these should be 2 different customizations, but in practice I don’t know how to implement this… Any advice for someone new to customizations on good design principles given the limitation of Epicor customizations?
Just do all you are going to do in 1 customization and don’t overthink it
Customizations are just one level deep. There is no stacking or combining.
Your first customization will start with the “Base” (un-customized form). You’ll need to uses “Save As…” to give it an ID (you can’t overwrite the base). Say we dao this and I call it "E10H_01"
Now if you go to make another customization, you can start with either the base, or choose any existing customizations. I could select the base, make some changes, and save as "E10H_02".
But any changes in E10_02 would not include the changes that were in E10_01.
If I select E10H_01, make some changes and then save as E10H_03, then that is a customization that has what E10H_01 plus the changes you just did. But they are not linked in any way. If you modify E10H_01, that would have no effect on E10H_03
Just like if you open a word doc, make changes and then save as a new doc. The new doc is oblivious to any prior versions.
One last thing.
The key fields for customizations are Company and ID. So you can have two customizations with the same ID, as long as the are for different companies. And note that “All companies” would be a “company” too. In the following one of these two customizations with the same ID is for a specific company, and the other is for All Companies
I believe those are shown sorted by Company, then by Customization ID. And since “All Companies” is actually a blank value, they are always listed first.
I think in Kinetic you will have the option for layers like you want. I think that’s there in 10.2.700 already.
But that’s Kinetic, not the screens like @ckrusen’s picture.
Did @ckrusen just refer to himself in the third person?
Well, buckle up, Calvin. The future is a-comin.
He does that every now and then.
Seems like an akward design just having 1 level of customizations. As an example today I spent an hour unlinking every label from every checkbox in the part entry screen(Checkboxes clickable area extends beyond just checkbox). Then completely unrelated, I added some new UD fields to the part entry screen.
What if 5 years from now we started using touchscreen devices and that “nasty Epicor checkbox bug” is no longer a bug and now we want the checkbox linked to the label as it makes it easier to click a checkbox. How would I rollback that customization but leave the other unrelated customizations(e.g. custom UD fields that we added). If you take that thought a bit further, I start thinking why is there no version control. These seem like pretty basic widely accepted good software design principles so I feel like I must be missing some feature or workflow…?
Kinetic works in layers and in five years, let’s all hope were there! 
The problem is, what if one customization moves a control to the top right corner of a panel and adds a control to the top left, then another customization adds a control to the top right of the same panel thinking the other control is still in the original location? As much as it would be great to have different UI changes be associated with different solutions, I just don’t know how they would implement it.
I’m no expert, but isn’t that a standard version control type problem? I think merge conflicts might be the right term. That is I don’t think this an Epicor problem, I think this is a general problem in software engineering that I believe has been solved.
In a way, it is. What I’m thinking is having a feature set in solutions that you can either include or not. So I could create a solution that will add a feature and send that to you to be installed. If that solution has interface changes, merging those interface changes with whatever other solutions you have isn’t (as far as I’m aware) a problem that has been solved without manual intervention.
Maybe I’m going tangential to the original posters query.
I agree Andrew, it hasn’t been solved. The closest solution I’ve seen is to use Feature Flags. Epicor 10.2 has them but as far as I can tell, they are only for Epicor’s usage.
After thinking about this for a minute, I think the web world is different than WinForms. In the web, absolute placement doesn’t really happen any more. We need to flow objects based on the size of the device that we’re using. With Kinetic, these kinds of things become possible where with WinForms, not so much.