Adoption training should cover workflow placement, human decision rights, and exception handling—not just interface navigation. The cited guidance shows a human review step after a prompt action and an approval action that starts the flow, waits for approvers’ response, and only then allows the run to complete.
What the training should cover
1. Where review belongs
Learners should understand the sequence:
prompt action → human review → approver response → run completion
One cited example explicitly places human review after the prompt action. Training should therefore help learners locate that review point in the workflow being adopted, rather than treating it as an isolated control or button.
2. What happens while approval is pending
An approval action is more than an interface element. The cited documentation says that a flow using this action starts and then waits for the approvers’ response before completing the run.
Training should make the distinction between these states clear:
- The flow has started.
- The run is waiting for approval.
- A response has been submitted.
- The run has completed.
The documentation does not establish universal interface labels or state names, so learners should be shown the behavior in the actual workflow configuration being considered.
3. Who has authority to respond
The existence of an approver does not determine who should be an approver. Adoption training should help the team define:
- which person or role may review the action;
- who covers an absence;
- whether the person who initiated the workflow may also approve it; and
- where those responsibility rules are recorded.
These are local governance decisions. They should not be presented as settings or requirements established by the cited documentation.
4. What happens when the expected response does not arrive
Training must also distinguish documented behavior from unresolved cases. The cited facts establish a waiting mechanism, but they do not provide a complete rule set for rejection, delay, unavailable reviewers, retries, or failed runs.
Until those cases are confirmed, the team should not imply that every possible response follows the same completion path.
How to check understanding
An evaluator can verify that training has moved beyond interface mechanics by asking the learner to:
- Point to the prompt action and the human-review step that follows it.
- Explain what the run does between starting and receiving the approvers’ response.
- Identify who is authorized to respond in the team’s own workflow.
- Describe what happens after approval.
- State what happens after rejection, delay, or reviewer unavailability—or explicitly identify those behaviors as still unconfirmed.
The check should test whether the learner understands the workflow and its decision points, not merely whether they can repeat click instructions.
What the team must still confirm
The two cited references support a specific review-and-wait pattern. They do not establish a universal adoption policy. The team must still confirm:
- whether every prompt action requires human review or only selected cases;
- how reviewers are selected and delegated;
- what each available response causes the workflow to do;
- how rejection, timeout, and unavailability are handled;
- what work has already occurred before the review point;
- what actions, records, or notifications follow completion;
- which access, privacy, security, audit, or regulatory requirements apply; and
- whether the configured workflow behaves as documented.
Until those answers are documented, training should present human review and approval waiting as the two confirmed elements—not as a complete governance or exception-handling framework.