Why should I not assign org units to steps in the workflow builder?
Using org objects such as positions or org units in the WF builder is not a good idea in most cases. Aside from number range mismatches when you transport, if your department splits or changes you need a transport for what should be a simple
maintenance task.There are a few ways around it. The simplest is to not assign any agents in the WF but to assign your recipients as possible agents of the task (which you can assign in each system, including PRD). If WF cannot determine actual (because you’ve left it blank), it will send the task to all possibles. Just be very careful not to declare them as general tasks because it will then go to ALL people in the system.Alternatively create a simple responsibility rule with a dummy responsibility and use that in your WF. If you’re feeling adventurous you could even design a ‘meta-rule’ with multiple responsibilities for different tasks/steps. This way you can maintain multiple steps’ agents in one rule.
Workflow : Other Useful Links :
‘No Administrator found’ workflow error
LIV & Payment Release workflow
Workflow performance tips
Viewing another user’s workflow inbox
How can I temporarily disable a workflow in production?
Raising ABAP OO events for workflow