Workflow Part 3: Agent Determination and Rule-Based Assignment

📌 KEY POINTS
✅ The actual recipients = responsible agents (from the step) ∩ possible agents (from the task), minus excluded agents.
✅ Responsible agents come from org objects (org unit, position, job), expressions (container elements like the requester's manager) or rules (PFAC: responsibility rules or function-module rules).
✅ A task marked "general task" allows all users as possible agents — convenient, but less controlled.
⚠️ If no agent is found (and the rule doesn't terminate on error), the work item goes to all possible agents — for a general task that can mean everyone in the company.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 2 built steps. Now each dialog step needs the right people.

━━━━━━━━━━━━━━━━━━━━
▶ 1. THREE AGENT SETS

• Possible agents: assigned to the task (PFTC → agent assignment) — who may ever execute it; or "general task".
• Responsible agents: defined per step — who should execute it in this case.
• Excluded agents: e.g. the requester must not approve their own request.
• Recipients = responsible ∩ possible − excluded.

━━━━━━━━━━━━━━━━━━━━
▶ 2. WAYS TO DEFINE RESPONSIBLE AGENTS

• Organizational object: org unit, position, job, user (PPOME).
• Expression: container element with an agent (e.g. &Approver& filled by a method).
• Rule (PFAC):

– Responsibility rule: table of responsibilities by criteria (e.g. plant, cost center range → positions).
– Function-module rule: custom FM with container input returning actors (interface with AC_CONTAINER and ACTOR_TAB).
– Org-structure rules (e.g. manager of org unit).

━━━━━━━━━━━━━━━━━━━━
▶ 3. RULE FUNCTION MODULE

• Reads criteria from the rule container (e.g. cost center), determines agents (e.g. from OM or a Z table), fills ACTOR_TAB with OTYPE 'US' + user or 'S' + position.
• Raises NOBODY_FOUND if none — combined with "terminate if rule resolution without result", this puts the workflow into error instead of routing to all possible agents.

━━━━━━━━━━━━━━━━━━━━
▶ 4. SUBSTITUTES AND FORWARDING

• Users define substitutes (SBWP) for absence; active or passive substitution with substitution profiles.
• Admins can forward work items (SWIA) to other users.

━━━━━━━━━━━━━━━━━━━━
▶ 5. TESTING RULES
PFAC → "Simulate" with test container values; SWI1 log shows agents determined per step.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

1. PFTC: check the possible agents of your approval task.
2. PFAC: create a function-module rule (code example) and simulate it.
3. Use the rule in the user decision step and set "terminate if rule resolution has no result".

✅ CHECKPOINT: you can configure agent determination safely with rules and understand recipient calculation.

After a reorganisation, a purchase requisition approval work item appeared in the inbox of 4,000 users. The task was a general task, and the rule found no approver for a new cost center — without "terminate if no result", the work item went to all possible agents.
The fix: mark the rule to terminate, maintain the new cost centers in the mapping, and restrict possible agents to an approver role. Unassigned cases now go to workflow administrators as errors instead of the whole company.

• General tasks combined with rules that can return nothing.
• Hard-coded user IDs in templates.
• Missing excluded agents (self-approval).
• Rules not updated after reorganisations.
• No simulation before transport.

• Restrict possible agents.
• Rules with NOBODY_FOUND and terminate option.
• Exclude requesters from approval steps.
• Base rules on OM or maintained tables.
• Simulate rules in PFAC and check logs.

Questions: "How are workflow agents determined?", "What is a general task?", "What happens if a rule finds nobody?"
Strong answer: recipients = responsible ∩ possible − excluded; responsible via org objects, expressions or PFAC rules (responsibility or FM rules with AC_CONTAINER/ACTOR_TAB and NOBODY_FOUND); general task = everyone possible; no result without terminate → all possible agents; substitutes, forwarding, PFAC simulation.