Functions, Widgets, and Custom Code - What's the Diff?

Good morning,
I am doing my best to hold off migrating my customized dashboard to kinetic until we get K21. Until then, I figured I should dig into some of the new features and… functions.

In Epicor Function Maintenance, I created a new library for myself, and proceeded to add one of each of the three new function types. Widget function, widget function with code, and custom code function.

I see that widget function does not allow custom code. Simple enough.

I also see that the widget function with code DOES allow custom code. Also easy to get.

What is the custom code function for? Why not just use the widget function with code?

Looking through the help files, I don’t see any examples of when to use each type of function. Can anyone give an example of when you might use each of these three types of functions?


1 Like

That’s a good question, will be interested to see the replies.

Hey Nate,

Hope this finds you well. I took a course on Functions and the only info they gave regarding Custom Code Functions was that it allows you to take a code first approach. If you don’t want to use the workflow designer, you would create a “Custom Code Function” rather than a function with code widgets.

Doesn’t answer the second part of your question - I’m not sure what advantages this gives other than some people prefer typing to drag and drop? Hopefully someone with a more comprehensive understanding can further articulate.

I ran a quick test with one my existing functions that was originally a single custom code block. I copied the code in the code block into the editor, added a few using statements, and it appears to work identically to the original one.


That is a great question… and I dont know that I have the “final” answer. But here is my theory.

  1. a custom code function is one where you have no other widgets… it is all code.
  2. the widget function is one where you combine both concepts. you have some widgets that might take advantage of some of the quick coding a widget can provide, but then you have a code block that is just easier to do in code…

One example of a “code” widget block that I started doing a long time ago was when I wanted to assign a bunch of parameters. Yes, you can do that (one parameter per widget), but if you have 10 parameters to set, it starts getting cluttered… but you can open one C# widget, and do all the assignments in the code fairly simply and cleanly without writing detailed logic.

Anyway… BPMs also had the concept of a code BPM, but i never used it. I always created widgets, (even if I only had ONE). But Typically I would have a C# widget which also might optionally set a variable that I created (called “dBugMessage”) and then I used two more widgets to check if dBugMessage was populated, and if it was, it would use a display widget to show the dBugMessage. This allowed for easier debugging that was also easy to “turn off” by simply changing the condition widget. I would leave the dBugMessage logic in the C# widget alone just in case in the future i needed to do more debugging.


Nice Tim, thanks for the example.

Sorry, Tim, but BPM does not have such a thing as “code BPM”. And never had.

Answering the original question…

@wcouch is right. The Custom Code Function is for scenarios when a developer wants to write the code only. Also, Custom Code Function Editor provides much more functionality than Custom Code Action/Condition Editor.

I would say that Custom Code Function is for CSF/partners mostly.

And don’t forget that neither WF-based with Code nor Custom Code functions are available in MT cloud environment.

Hello Sergey!

How much would you be able to simplify the code base if Multi-Tenant were eliminated and all cloud users were either Dedicated or Single Tenant? The limitations of MT are a drag on the entire cloud effort for Epicor. It is confusing to potential cloud users who hear about all of these limitations about a product that is no longer sold that would not even apply to them as Public Cloud users.

1 Like

I think removing of MT from the product line would allow to simplify code significantly and make it less fragile. Also, it can unblock some possibilities in the optimization of the upgrade process.

But, it is my personal opinion. Company and/or other employees can have different one.