Hi @tburt, thank you for your response!
If this is truly a bug, why is SailPoint recommanding using it in this way in the video @colin_mckibben shared here?
Being able to manually call an enabled workflow is used for:
- Workflows, that should be called on both a specific trigger, but also on an ad hoc basis.
- Workflows that use recursion and should be able to call themselves. For example to deal with pagination.
- Workflows that failed due to external factors (can’t disable account as source is disconnected) and should be retried.
- Org Admins that want to execute a workflow with ad hoc trigger (external trigger) through a script or postman, using the default Personal Access Token they use from there. After all, if they are org admin, they can execute the steps in the workflow in the workaround you suggest anyway, so might as well allow them to call the workflow itself properly while it is in enabled state.
Your “'bugfix” is breaking all this already build and used functionality.
Besides breaking this functionality, I also don’t agree with the statement that this change closes the loophole in how the API works. It is not a loophole to begin with as we actually need this, but even if it was. You are literally saying how you can use a loophole to circumvent the closure of this “loophole”. So the “issue” is still not solved. Those who could do this before can still do this, but just with more tedious steps.
Besides requiring more actions, another downside of this loophole of this “loophole” would be that the workflow execution is now at a different location, and if the workflow uses recursion and calls itself, the duplication will not use recursion upon duplication as it still references the original workflow. As a consequence, different iterations of workflows will now have executions in different locations as well, adding more chaos to the process.
Besides this we would then have to have twice as many workflows. One is enabled mode and one in disabled mode. Disabled would usually suggest here that it is not being used, but due to your suggestion, we actually have to use these workflows in disabled mode in production for it to work at all.
I strongly request to revisit this strategy.
Kind regards,
Angelo