Change requests and rule-based workflow
What actually happens between Submit and Activate: change request types, the generic workflow template, the three BRFplus decision tables and the BAdIs that make agents dynamic.
From a click to the rules
A change request (CR) is the container for one governance case; its header lives in USMD120C. The CR type defines data model, main entity, UI and workflow (MDGIMG → General Settings → Process Modeling → Change Requests). A business activity links the user's intent (create, change, mark for deletion) to the right CR type.
One generic template, many processes
Rule-based workflow uses one template, WS60800086, that loops: "step done with this action, what next?" BRFplus decision tables per CR type answer. The template never changes and the process lives in readable data, but it is spread over rows nobody sees as a graph until you draw it.
The three decision tables
USMD_SSW_RULE opens three tables per CR type. Single value (DT_SINGLE_VAL_<CR type>): previous step + action → next step and CR status. User agent (DT_USER_AGT_GRP_<CR type>): who works a person's step. Non-user agent (DT_NON_USER_AGT_GRP_<CR type>): which service a system step calls, such as activation. A condition alias links them.
Try it: name the tables
Complete the description of rule-based workflow configuration.
Open the tables for a CR type with . The table maps previous step + action to the next step. People's steps get agents from the table; system steps such as activation are set in the table. A links the rows.
Reading the step graph
Each single value row is an arrow from (step, action) to the next step. Walk the graph built from the table above.
When rows are not enough: BAdIs
When the answer depends on data in the CR (approver by plant or purchasing org), rows explode. Use a BAdI instead, and read its interface in SE18 on your release before coding.
METHOD if_usmd_ssw_dynamic_agt_select~get_dynamic_agents.
" Called for a step whose decision table row asks for dynamic agents.
" 1. Read the CR number and step from the importing parameters
" 2. Read the CR's entity data (e.g. MARCBASIC for the plant)
" through the MDG model API, from staging
" 3. Look up approvers in a custom table ZMDG_APPROVER by plant
" 4. Append them to the agent table (user or org object)
" 5. If nothing is found, return a fallback group, never empty
ENDMETHOD.Outline only. Check the interface and signature in SE18.
Try it: which BAdI?
Match each BAdI to what it is for.
Rows or code?
Debugging a stuck change request
Work outside in: CR status and log in the MDG UI, then the workflow log (SWI1) to see the step, agents and any system-step error, then the decision table row for that step and action, then agent tables and BAdI code. The same order makes a good prompt: give an assistant the status, log extract and table export.
Try it: stuck for one plant only
Material creation CRs work for every plant except a newly onboarded plant 3000: after Submit, nobody gets a work item. The single value table rows look fine. Approvers come from the dynamic agent BAdI. What do you check?
Remember
- CR type, business activity and the generic template WS60800086 connect a user action to the rules.
- The single value, user agent and non-user agent tables drive every step; read the first as an edge list to find missing paths.
- Data-dependent approvers come from the dynamic agent BAdI, not from more and more rows.