We’re experiencing a frustrating workflow issue with our incident management process. When a manager rejects an incident report and sends it back for corrections, the workflow loops back to the initiator as expected. However, after the initiator makes edits and resubmits, the workflow doesn’t progress to the next approval step - it just keeps cycling back to the initiator.
The workflow state transitions seem stuck in an edit-resubmit loop. The initiator receives the rejected report, makes the requested changes, clicks ‘Resubmit for Approval’, but instead of moving forward to the manager’s queue, it bounces right back to them with a message saying ‘Pending Your Review’.
I’ve checked the edit and resubmit permissions, and the initiator role has ‘Edit Own Records’ and ‘Resubmit After Rejection’ enabled. The incident closure logic appears correct - incidents should only close after final approval, not during the revision cycle.
This is blocking our incident closure process completely. We have 12 incidents stuck in this loop right now. Has anyone seen workflow state transition issues like this in qual-2022.2?
Look at the permissions more carefully. Even though initiators have ‘Resubmit After Rejection’, check if they also have ‘Approve Own Records’ permission. If they do, the system might be treating their resubmit action as an approval attempt, which then fails validation and loops back. Remove any approval permissions from the initiator role and test again.
I suspect there’s a validation rule that’s being triggered on resubmit. In qual-2022.2, there’s a feature where you can set field validation rules that run on state transitions. If a validation fails, the workflow stays in the current state. Check if there are any required fields or validation rules that aren’t being satisfied when the initiator resubmits. Look at Admin > Workflow Configuration > Incident Workflow > Validation Rules.
Another thing to check - the workflow step assignment. When an incident is rejected and sent back, is it assigned to the initiator as an individual or to the ‘Incident Initiators’ role? If it’s role-assigned and the initiator is part of that role, the resubmit might be trying to assign to the same role again instead of progressing to the manager step. The assignment logic needs to explicitly route to the next approver, not just ‘next step’.
Excellent troubleshooting by everyone. Let me provide a comprehensive solution that addresses all three focus areas for this incident workflow loop issue.
Workflow State Transitions:
The core problem is typically in how states and transitions are configured. Here’s the correct setup:
-
Define Clear States:
Navigate to Workflow Designer > Incident Management > States:
- Draft (initiator creating)
- Pending Manager Approval (awaiting first review)
- Pending Revision (rejected, awaiting initiator edits)
- Pending Final Approval (after revision, awaiting manager re-review)
- Approved (final state)
- Closed (incident resolved)
-
Configure Transitions Correctly:
The key is the transition from ‘Pending Revision’ state:
Go to Workflow Designer > Incident Management > Transitions > ‘Resubmit After Revision’:
- Source State: ‘Pending Revision’
- Target State: ‘Pending Final Approval’ (NOT ‘Pending Manager Approval’ or ‘Draft’)
- Trigger: User Action ‘Resubmit’
- Assignment: ‘Previous Approver’ or specific ‘Manager’ role
- Clear the ‘Reassign to Initiator’ checkbox if present
-
Check for Conditional Routing:
Review all decision nodes in the workflow:
- Look for conditions like ‘If modified by initiator’ → these can create loops
- Ensure conditional branches don’t override the explicit resubmit transition
- Remove any ‘Return to initiator for validation’ logic that might be catching resubmissions
-
Verify State Machine Logic:
In qual-2022.2, check the workflow properties:
- Admin > Workflow Configuration > Incident Workflow > Advanced Settings
- Ensure ‘Allow state skip’ is disabled (forces explicit state progression)
- Check ‘Transition priority’ - explicit user actions should have higher priority than automatic routing rules
Edit/Resubmit Permissions:
Permissions need to be precisely configured to avoid conflicts:
-
Initiator Role Permissions (Admin > Roles > Incident Initiator):
- ✓ Create Incident Reports
- ✓ Edit Own Records (only in ‘Draft’ and ‘Pending Revision’ states)
- ✓ Resubmit After Rejection
- ✗ Approve Own Records (MUST be disabled - this is often the culprit)
- ✗ Change Workflow State (should only happen via defined transitions)
-
State-Specific Permissions:
Configure permissions per state to prevent unintended actions:
- Draft state: Initiator can edit all fields
- Pending Revision state: Initiator can edit specific fields only (those mentioned in rejection comments)
- Pending Manager Approval / Final Approval: Initiator has read-only access
- Use field-level permissions: Admin > Incident Configuration > Field Permissions > set by State
-
Action Permissions:
For the ‘Resubmit’ action specifically:
- Admin > Workflow Actions > Resubmit Action
- Available to: ‘Record Owner’ when state = ‘Pending Revision’
- Required fields: Ensure all mandatory fields are completable by initiator
- Validation: Run validation before state change (see next section)
-
Remove Conflicting Permissions:
Common permission conflicts that cause loops:
- Initiator with ‘Approve’ permission tries to approve but lacks authority → loops back
- Initiator with ‘Assign to Others’ permission might accidentally self-assign
- Check audit log: Admin > Audit Trail > filter for these incidents to see what actions are actually being attempted
Incident Closure Logic:
Ensure the workflow properly handles the revision cycle without closing prematurely:
-
Closure Conditions:
Define explicit closure criteria:
- Admin > Workflow Configuration > Incident Workflow > Closure Rules
- Incident can only close when state = ‘Approved’ AND all required fields completed AND closure checklist confirmed
- Prevent closure during revision cycle: Add condition ‘State NOT IN (Pending Revision, Pending Final Approval)’
-
Validation Rules on Resubmit:
This is critical and often overlooked:
- Admin > Workflow Configuration > Incident Workflow > Validation Rules
- Create validation rule for ‘Resubmit’ action:
- All required fields must be filled
- Corrective actions must be documented (if that was the rejection reason)
- Attachments must be present if requested
- If validation fails, workflow STAYS in ‘Pending Revision’ state and shows error message
- In qual-2022.2, failed validations don’t always show clear error messages - check System Logs > Workflow Engine for validation failure details
-
Rejection Comment Handling:
Ensure rejection feedback is properly captured:
- When manager rejects, require ‘Rejection Reason’ field
- Make this field visible to initiator in ‘Pending Revision’ state
- Add validation on resubmit: ‘Initiator Response to Rejection’ field must be filled
- This ensures initiator actually addresses the rejection before resubmitting
-
Approval History Tracking:
Configure proper audit trail:
- Enable ‘Track Approval History’ in incident configuration
- This prevents confusion when incident goes through multiple revision cycles
- Shows: Initial submission → Rejection → Revision → Resubmission → Final Approval
Debugging the Current Loop:
For the 12 stuck incidents, here’s how to diagnose and fix:
-
Check Workflow State:
- Open one stuck incident
- View > Workflow History
- Look for the state transition sequence - it should show the loop pattern
- Note what state it’s returning to
-
Review Validation Failures:
- Admin > System Logs > Workflow Engine
- Filter by incident ID
- Look for entries like ‘Validation failed on transition’ or ‘Required field missing’
- This will show the hidden validation that’s preventing progression
-
Manual State Correction (temporary fix):
- For stuck incidents, you may need to manually advance them:
- Admin > Workflow Configuration > Incident Workflow > Manual State Change
- Select stuck incident, change state to ‘Pending Final Approval’
- Manually assign to the manager
- Document this intervention in incident notes
-
Prevent Recurrence:
- Fix the root cause in workflow configuration (state transitions, permissions, validation)
- Test with a new test incident through the full rejection → revision → resubmit cycle
- Monitor for 48 hours to ensure no new incidents get stuck
Testing the Fix:
Create a test incident and run through this scenario:
- Initiator creates and submits incident
- Manager rejects with comments
- Verify incident moves to ‘Pending Revision’ state and assigns to initiator
- Initiator edits and clicks ‘Resubmit’
- Verify incident moves to ‘Pending Final Approval’ and assigns to manager (NOT back to initiator)
- Manager approves
- Verify incident moves to ‘Approved’ state
- Close incident
- Verify closure completes properly
Check workflow history at each step to confirm state transitions are correct.
This comprehensive solution addresses the state transition logic, permission configuration, and closure handling to eliminate the approval loop issue.
I’ve seen this before. The problem is often in the conditional logic on the workflow transitions. If you have a condition like ‘If edited by initiator, return to initiator for validation’, that could override the resubmit action. Check for any conditional branches or decision nodes in your workflow that might be catching resubmitted incidents and routing them incorrectly.
This sounds like a workflow state machine issue. Check the ‘Resubmit’ action configuration. It might be transitioning to the wrong state. The action should move the incident from ‘Pending Revision’ state to ‘Pending Manager Approval’ state, but if it’s configured to transition to ‘Draft’ or ‘Pending Initiator Review’, that would create the loop you’re seeing.
Found it! It was a combination of the state transition configuration and a validation rule. The resubmit action was moving to the right state, but a hidden validation was failing. Thanks for all the pointers!