Pausing a workflow until a named person approves

Resolve the approver to an account, create one approval request for that person, and release the wait only for a valid decision on that request. A notification shows who was asked; it does not, by itself, prove who responded.

For an equipment request assigned to a team lead, decide how the lead is chosen, whether another person may take over and what happens to the original assignment after reassignment.

Resolve the assigned person

Start with the business rule: the record owner, the holder of a role when the request is issued, or a person selected by an authorised requester. Resolve that rule to an eligible account and retain both the rule and account ID. A display name alone is a poor identifier because names can be shared or changed.

Power Automate’s standard approvals connector accepts an email address, user principal name or Microsoft Entra ID user ID in its AssignedTo field. Those are recipient formats for that connector.

Check that the selected account can view the business record and use the chosen response channel. If no eligible person is found, hold the action and assign the routing problem to an owner.

Bind the response to the waiting request

Keep an approval ID, business record reference, reviewed terms, assigned account, intended action, deadline and waiting state. The request record should remain identifiable even if its notification is delayed or lost.

Power Automate’s Start and wait for an approval creates and waits in one action. The connector also offers a Create an approval action, which starts an approval but does not wait for it to complete.

An AWS Step Functions task-token callback can pause a supported Standard Workflow integration. The token resumes the task when returned through the AWS API; it does not identify or authorise the human on its own.

Keep that token out of a public response link. The response application should authenticate the person, check their authority and send the result to the correct waiting task.

Accept one authorised outcome

At the decision gate, check that the approval ID matches the wait, the request is open and within its deadline, the authenticated responder is currently authorised, and the response is allowed. Record the accepted responder, outcome and time. A repeat response should leave the accepted outcome unchanged and must not release the action a second time.

Make substitution explicit: record who may reassign, the previous and new assignee, and whether the earlier response route is invalid. When reassignment is authorised, invalidate the earlier response route before sending the request to the new assignee, and accept a response only from the current assignee.

On rejection, follow the rejection route. On approval, check that the reviewed business terms still qualify before the sensitive action runs.