Submit is not the same as “someone got it”
I get this call more than almost any other MDG issue: “We submitted the change request. Nothing happened.”
Often something did happen. The request left draft. Staging has the data. The status moved. What did not happen is a work item in the right person’s inbox. From the requestor’s chair it looks stuck. From the system’s chair it is waiting on an agent who was never determined, or on a task that never became a general task.
I stop guessing and open the workflow log for that change request.
What I look at first
On the change request, I open the workflow or process log (the exact label depends on your UI, but you want the technical log for the running instance, not the business note).
I want three facts:
- Which step ran after submit.
- What status the change request moved to.
- Which agent the system tried to assign — user, role, position, org unit, special agent, or blank.
If the log shows a step with no agent, or an agent who cannot open the MDG worklist, that is the whole problem. Fancy redesigns can wait.
If there is no workflow instance at all after submit, the change-request type is not starting a template, or the template failed before the first step. That is rarer, but I check it before I touch decision tables.
Agent blank or wrong
When the log shows a blank agent after the first dialog step, I go to the rule-based tables for that change-request type — usually via MDG process modeling or USMD_SSW_RULE when the template is the rule-based one.
DT_SINGLE_VAL_ should have produced a condition alias for the step after creation (step 00, blank action). If there is no matching row, there is no next step. The request sits.
If there is an alias, it must land on exactly one agent table. On DT_USER_AGT_GRP_ I check the agent type and value. A hard-coded user ID fails the day that person is out. A role or position is what I expect in a landscape that has to survive leave and rotation.
I have also seen a leftover sample alias from a copied material type. The new type looks “configured,” then every submit follows a sample path nobody uses. Delete the sample rows you are not running.
Agent looks right, still no work item
This one burns hours.
The table returns a role. The role has the right users in PFCG. The log even names a person. Still no work item in their MDG inbox.
Two checks I run every time:
- The dialog task for the workflow template is a general task in the MDG agent assignment. If it is not, a correct role still produces nothing the user can see.
- The user can actually open the MDG worklist for that object type. Missing authorization looks like “stuck” from the outside.
I fix the task or the role. I do not retarget the BRFplus row to a personal user ID just to clear the ticket. That creates the next stuck request.
Status moved, process did not
Sometimes the status after submit is not the one the business expects. The log shows a system step — activate, complete, roll back — that fired too early because DT_NON_USER_AGT_GRP_ had the wrong alias, or because an alias sat on both agent tables and the runtime took the system path.
I correct the alias ownership first. One alias, one table. Then I retest with a fresh change request. Editing a half-dead instance is a bad way to prove the design.
Parallel steps need the merge type set before you trust the happy path. I have watched finance reject while sales approved and a third item stayed open, then watched replication follow whoever hit activation first. That is not “stuck after submit,” but it shows up in the same log conversation, so I mention it when the log shows multiple agent groups on one parent step.
Four things I verify before I call it fixed
I use a plant-recognizable object on the real change-request type. Then:
- Submit creates a work item for the expected role (not a named holiday).
- Reject at the first review returns a comment the requestor can see.
- A request that should match no row does not fall through to a catch-all user. Empty is better than wrong.
- Transport: change-request type and BRFplus application travel together, tables activated in the target. A type that arrives alone has no processor. The runtime did not lose the step. The transport did.
What I tell the requestor
“Stuck after submit” is almost never a mystery once the log is open. It is usually a missing row, a sample alias, a personal user ID, or a dialog task that is not general.
I fix that path. I do not rename the change-request type or invent a second Flexible Workflow scenario for MDG staging. The configurable path for a rule-based MDG change request is still the template on the type and the three decision tables behind it. The log tells you which of those failed.