Currently, the design for the Offboarding V2 has a number of failure blocks and logic to check for pre-reqs. One of these pre-req blocks can error directly into a failure block (consisting of NOOPs). Which then stops the automation dead (which is logical). The issue is at this point in the workflow, no ticket was generated, no email was sent, there is nothing outside of watching Rewst logs to denote what's happening. And in this case, a failure monitor wouldn't work as the automation outputted as a success. A success monitor would work, abeit if you configure it properly to parse the various outputs. For new customers, or those who just aren't watching executions constantly this is a problem as a non-rewst user can submit the relevant form, and there is no record whatsoever outside of Rewst that it failed to proceed normally. This can then theoretically lead to a state where a customer (who was told, submit the Rewst form), expected access to be revoked, only to find later that no ticket was ever generated, and the end user is still able to login. My opinion here is this crate should still have some form of "Failure Handling" if certain processes, like pre-req checks are failing. The technical standpoint of "the workflow is succeeding because we have good error handling" is excellent from a technical view, but from a user experience POV, it can be a critical flaw, especially if a "technical success but process failure" execution resulted in a user who was slated for offboarding remaining for days, weeks, months, etc.
