Please note @colin_mckibben that your suggestion does not work in several cases.
Using his suggestion means that executions may be missed due to this workflow being disabled while retrying the original failed workflows. And the ones you miss can not be retried because they never failed to begin with due to them being missed. Because of this, I would consider this workaround an antipattern that should not be followed in production, unless it is specifically known that this workflow will not be triggered in the meantime.
Another reason why this fails is when the workflow uses recursion (for example these ones), this will also fail, because you have disabled the workflow you want to call.
So in summary this suggested workaround is not working when you use recursion, or when need the workflow to stay enabled for new executions.
I strongly suggest SailPoint to come up with a proper solution to this, such that we can securely keep using recursion, retrying and (as admin) manually trigger workflows that are enabled while being able to (as admin) test workflows that are disabled (also figuring the use case where a disabled workflow should be tested that would apply recursion on itself).
Kind regards,
Angelo