Multiple Programmerson same screen with different request

Any body know…
if there are Multiple Programmers on same screen with different request,
how it able to handle the customization deployment?
There is only one customization can be choose in menu maintenance.
Is it possible to merge different customization to 1 customization?
Or other way we can do it?

Customization info is stored in the DB as records, with the form name and customization ID as well as some others) as the keys.

So I would assume each developer would see the “This record was changed by another user…” messages whike working on the customization. And that’s assuming it lets multiple users enter customization mode at the same time.

It would be a nice feature if it locked the customization records to the first user that entered that mode. Like how an AR Invoice Entry group can only be open by one user at a time.

There is a WIP checkbox in customization maintenance which we use to “checkout” a customization.
When we are done we back in and the next guy can take it

1 Like

I always thought the WIP flag was to indicate that it should not be deployed.

Is there any enforcement by the system? Is a user prevented from entering customization mode, if that WIP box was checked by another user?

No, no enforcement. But its a clear way to see if someone is actively developing in the form.

1 Like


Thanks your replies.
So, it seems that Epicor Developer mode cannot allow multiple customization on the same screen, right?

You can. But, you’ll need to create additional menu names…each calling the unique customizations.


Or… what we do is for a spcific form, any changes is made by one developper, so the different requests of changes are done either simultanously or subsequently of each other… saving a different version names.

Otherwise, you would need to merge all the changes made from all the developpers… Having different menu items can be confusing in the long run…and more work to maintain.


Until there is built in version control if ever it comes down to process and discipline. Ideally one developer at a time works on a screen. That isn’t always practical though.
My experience is each developer works on their piece on their own in a copy of the original. When the time comes to release they have the responsibility to get the most recent release and do a compare/merge of the changes. Winmerge is one tool I use. After they do a merge, they redo all their testing. While it gets messy giving each new release a new name has saved a lot of grief in avoiding losing work due to overwriting. When you release to LIVE if you want you can release using a simple name.