Change Notes for Customizations

I have reached the conclusion that we need to have a better way of organizing my company’s customizations and the way they interact with Epicor’s default behavior. I have used SharePoint sites to capture the customizations and how they’re supposed to work, the BPMs, BAQs, UD Fields, User Codes, and so on that they use, as well as some of the anticipated errors/troubleshooting. This is OK but it is not connected to Epicor in any useful way so I know this doesn’t receive any traffic from the user and it’s really only going to help the person (like me) who is trying to figure out why something isn’t working. It’s more of an Operator’s/Maintenance manual.

I want to communicate to the user whenever there is a change to a customization/dashboard/BPM. As an example, I recently re-did a BAQ that we use for Projected BOM Costs. The change I made was to include operations/subcontract operations in the main grid as well as changed how the cost is calculated to split between “material vs. labor”. This is easily explained in a couple sentences. I thought about creating a UD table that would be linked to the Menu path via a Child UD Table reference. Then I could essentially make an entry on the Menu Maintenance form to my UD table that I could conceivably show from the Help menu within the form I’ve customized. I don’t know what I may run into here and if there’s already a built-in way that Epicor wants us to handle this. What are you all doing?

As a related thought on this, I want to create a way to keep users trained on the various features of Epicor that are pertinent to their job. Is there a way to keep those “Trainings” in Epicor and what are any others doing regarding continuous education. Or do you use something outside of Epicor that keep these procedures and the requisite training information?

What are we doing? Something similar to you: manual documentation. What would we like to be doing?

Make Kinetic More DevOps Friendly - Epicor Ideas

In regular software shops, where they are in control of the entire coding cycle, many follow the DevOps cycle:


A request comes in, a plan is made, it’s coded, tested, packaged and then deployed. Start to monitor for performance and stability, and take in user improvements, and then the cycle repeats.

Now Kinetic is slightly different. We’re not writing code. At best we would get a JSON representation of any customizable object: MetaUI, BAQ, Directive, RDD, UD Fields, etc. A text-based version would make comparisons from base to any customized version immensely helpful. More importantly, we would have a Hash ID for each uniquely identifying each change. We would get that from a Git commit like code writers along with who made the changes, when, and the ability to roll back.

The final piece would be a build and deploy process so we could udpate our systems or even build environments from scratch. If we have all of our customizations in source control, we can take advantage of current tools like Azure DevOps or GitHub Actions to deploy changes in a controlled manner - because today, none of us makes changes in production. :thinking:

Almost four years ago, I wrote a LinkedIn article about the idea. I was also thinking about a more declarative model for maintaining ERP systems: DSC = Desired State Configuration. The idea is that we’d make business rules and run a PowerShell DSC agent to make sure our ERP systems stayed in a desired state from implementation through daily production.

Yeah, I know. :sweat_drops:

But back to basics, if we could utilize GitHub to store our customizations in a Git-friendly way, we could manage user requests, document our work (and provide a link to GitHub where users could read the details), have controlled releases, build dev environments, etc. It’s something I used to talk to Bart about at least five years ago since he was the only DevOps-minded person I knew at Epicor. I’m not sure who has taken on that role since he left. :person_shrugging:

Not asking to change much, just everything. :eyes:


1 Like

I added my vote. It’s a very good idea.