OK, I know that nobody is going to make the jump right to some Work Flow framework. So, one thing that helped me understand this pattern was learning about State Machines. Scott Hanselman has a nice blog explaining this in .NET Core. What the workflow frameworks do is handle this work for you, but it’s always good to know how it all comes together.
A way to ease into workflow in a low-code way is to use Azure Logic Apps. Logic apps is the engine behind Power Automate. Unlike Power Automate, one can run apps under a service account and not a specific user. Also, you can run Logic Apps in consumption mode, which can be very cost effective since you only pay for what you use. A Logic App can receive and make REST calls, which is all one needs to communicate with Kinetic. One would need to install the Azure Logic Apps Data Gateway so calls from Azure can hit your URLs on-prem. Alternatively, for more advanced shops who already run Kubernetes on prem, you can also run Logic Apps locally.
Could we write some state handling routines using a UD table? Sure. Would it be better than the tools out there? Not without a lot of time and effort. The point of this post is that we tightly couple our integrations which tend not to handle the non-happy path very well - as @JasonMcD mentioned above. Before Epicor Ideas, there was a suggestion to move notifications to a service. Right now, we put the handling of notifications right in directives, Epicor Functions, or Advanced Print Routing. What a pain it is to have to change code when email addresses change. There is no retry mechanism if the intial SMTP server is down. There’s no proof of delivery and no proper way to handle Do Not Contact requests.
Does it make sense to put all this kind of logic into every directive or Efx? Or would it be better to handle this common software architecture problem with tools that already exist?