A majority of the time we are currently using event rules and event definitions to run after a certain workflow state to replicate a post run LB in workflow. A majority of our eventing is done to based on WF on sales orders. What is the reasoning to use this dev method vs a LB on workflow? Is it just cleaner and more simple than messing with checking out/customizing/extending workflow?
Also, when would you set up the event definition to be event type of user defined event? How is that hooked up and kicked off?
From where I sit, a reason to use eventing in favor of post-transition LBs in workflow is to decouple the success of the subsequent transaction attached to the event from the success of the workflow transition.
Consider a post-transition LB that is responsible for transaction B. If it errors, the workflow transition (tranaction A) goes into an error state. This situation is what is known as tight coupling. Depending on the situation, this may be appropriate that transaction B and transaction A live and die together. But frequently, it is not. If transaction B merely needs to be attempted/start after transaction A has completed and can live independently of the workflow transition that triggered it, then eventing is the perfect framework for that.
Per Nextworld Help - User-Defined events are kicked off from logic blocks. What you get with these is decoupling - the logic and transaction owned by the event lives independently of the calling logic block. In some ways its similar to Queueing a Background Task, but Queueing a Background Task is limited to executing a logic block whereas Events can interact with services such as AWS Eventbridge. Background tasks also don’t have some of the capabilities native to eventing such as retry, and as such are not a great option if the logic has a chance of erroring.
Got it, thanks. Should I create a freshdesk ticket for that bug in order to track it?
Currently, is using the app monitoring tool the best way to see when event are being hit on a certain workflow?
And, how do you suggest we debug if there is no current way to do so for external event target defintions?
Lastly, since there is currently no debugging on events, is the best way to debug these event LBs by putting them on a row action on the app and then debugging from the UI?
Also consider using the Event Status Inquiry app for this.
There is no way to debug this. The closest mechanism available is simply to queue the event, have the event target fire, and monitor either the Event Target Delivery Status record or the Jobs record for any errors that occur during LB processing.
That could be a possible workaround for when the event targets are logic blocks, yes.
