Choose the symptom you can observe
Open the matching case. Check the existing state before changing a record or repeating an action.
Readiness names a missing prerequisite but gives no useful next step.
Check first
- Record the organization, franchise, period, and rule scope used by the readiness check.
- Read the blocker category and compare it with the linked setup or source record.
- Check whether another open item already owns the same missing prerequisite.
Next action
Assign the blocker to the owner of the source, rule, assignment, destination, or data issue it names. Keep the run unready until that owner resolves the actual prerequisite rather than adding a free-text override.
Confirm the result
The next readiness check names the same scope, shows the blocker resolved or intentionally deferred, and records the owner and time of the decision.
The team cannot tell whether a readiness message is a warning or a blocker.
Check first
- Compare the message with the run's eligibility, deferred, and blocked outcomes.
- Check whether the issue prevents invoice creation or only asks for reviewer attention.
- Confirm the acceptance authority for a warning before continuing.
Next action
Classify the message using the run's actual consequence, then record the reviewer decision. Do not treat every warning as safe and do not block indefinitely when an authorized reviewer has explicitly accepted a non-blocking condition.
Confirm the result
The readiness record separates accepted warnings from unresolved blockers and names the reviewer for each accepted exception.
Readiness still shows an old blocker after its source was corrected.
Check first
- Compare the source correction time with the readiness check time.
- Confirm the check used the same organization, franchise, period, rule, and destination scope.
- Look for a second source record or version that still carries the blocking state.
Next action
Recheck the exact run context after the source correction and route a stale result to the readiness owner if it persists. Do not approve the run from a screenshot or an earlier green state.
Confirm the result
A fresh readiness result reflects the corrected source version and shows the current blocker, warning, or ready state for the intended scope.
The readiness result is clear, but it covers the wrong run scope.
Check first
- Compare the readiness organization, franchise set, period, rule, and destination with the prepared run.
- Check whether the result was opened from a different saved run or browser context.
- Confirm that the run's preview and readiness timestamps refer to the same preparation.
Next action
Discard the unrelated readiness result from the approval decision and run the check for the prepared scope. Keep both references in the incident note if the wrong result could have caused an approval mistake.
Confirm the result
The approved run points to a readiness result with matching scope, timestamp, and blocker disposition.
Prepare a useful escalation
- Include the readiness check identifier, organization, franchise scope, period, rule, destination, blockers, and timestamps.
- Name the owner for each unresolved prerequisite instead of escalating a generic 'not ready' message.
- Ask the approval owner to confirm the final scope before a processing decision is made.
Reference the relevant record instead of copying credentials or unrelated personal information into the handoff.