Client Delivery
Part of Task and issue workflows
Configuring approval gates for project deliverables
An approval gate should stop a deliverable at the point where a named person must accept a specific version.
Build an approval gate as a Power Automate flow that starts from a SharePoint Online deliverable record, sends a decision request and records the result. Include the version under review in the request details, and decide who must approve and what happens after rejection.
Write the decision rule
Identify the deliverable, its acceptance criteria and the version reviewers must inspect. Decide whether any one reviewer can decide, every reviewer must respond or approvals must happen in a set order.
In Power Automate, use Approve/Reject - Everyone must approve when every approver needs to respond; the flow continues after all respond or one rejects. Approve/Reject - First to respond completes when any approver responds. Sequential approval sends requests one at a time, in a specific order.
For defined responses, choose Custom Responses - Wait for all responses or Custom Responses - Wait for one response. Choose the option that matches the decision authority; do not let a reminder or escalation silently change who can approve.
Set the rejection route before building the flow: return the deliverable to its owner, require comments and specify whether reviewers must see a revised version. A rejection should record a decision and a clear route forward.
Configuring an Approval Gate in Power Automate
- TriggerWhen a new deliverable item is created in SharePoint Online
- Approval TypeApprove/Reject - Everyone must approve or Sequential approval
- Review CriteriaVersion under review, acceptance criteria, and decision authority
- Rejection HandlingReturn to owner, require comments, and specify if revised version must be re-reviewed
- Outcome RecordingUpdate SharePoint list with approval status and manager comments
Approval Types in Power Automate
- Everyone Must Approve
- Flow continues only after all approvers respond or one rejects
- First to Respond Completes
- Flow continues as soon as any approver responds
- Sequential Approval
- Approvals sent one at a time in a defined order
Test a revision between decisions
Create a SharePoint Online list for deliverables with Title (single line of text), Comments (single line of text), Approved (Yes/No) and Manager Comments (single line of text). Use Title to identify the deliverable, Comments to note the version and review criteria, Approved for the result, and Manager Comments for decision notes.
In Power Automate, create an automated cloud flow with the SharePoint - When an item is created trigger. Add the Approvals - Start and wait for an approval action, then supply the approvers and the information they need to review the deliverable.
Choose the approval type in that action. After it completes, update the SharePoint list with the decision and comments, and send the requester an email with the decision. Power Automate can also start an approval when a new item is added to a list.
Include the version identifier in the approval request details. The request identifies what reviewers were asked to inspect; it does not, by itself, lock the file. Treat a material edit after submission as requiring a new approval request.
Test with a sample deliverable: have one reviewer approve it, then make a material edit before the next reviewer responds. Check which version each reviewer sees and whether the earlier decision is retained, qualified or needs renewal; document and apply the team’s rule.
Testing a Revision Between Decisions
- Create SharePoint list with required fieldsTitle, Comments, Approved (Yes/No), Manager Comments
- Set up automated flow with 'When an item is created' triggerStarts approval process automatically
- Include version identifier in approval requestEnsure reviewers see the correct version
- Test material edit before final approvalVerify whether earlier decisions are retained or require renewal
- Document team's rule on revisionsApply consistent policy across projects
Handle absence and delegated authority
In a company-managed Jira space, a Jira administrator with global permission can create or edit an advanced workflow. Model the gate as a transition between workflow statuses, use validators and custom fields to check the approval, and use a workflow scheme to associate the workflow with the relevant work type.
In a team-managed space, a space admin can create or edit workflows and add a rule to a transition to check a work item’s field. Use that transition rule to prevent the work item moving forward until the approval is recorded.
Check that the workflow is active for the relevant work type and that the people configuring it have the required permissions. Test the transition with an unapproved item as well as an approved one.
Specify who may substitute for an unavailable approver and how the delegation is recorded. A reminder requests attention; it does not confer authority. Keep required approvers separate from people who only need a notification after approval.
Delegated Authority vs. Notification Recipients
- Pros of Delegated Authority
- Ensures continuity during absence; maintains decision integrity
- Cons of Delegated Authority
- Requires clear documentation; risk of misuse if not tracked
- Pros of Notification Recipients
- Keeps stakeholders informed without altering approval rights
- Cons of Notification Recipients
- No decision-making power; may lead to confusion about accountability
Verify the result as an ordinary user
After acceptance, ask someone outside the approval group to open the deliverable. Check that they can identify the version, decision and any outstanding approval, then retain the decision and comments in the SharePoint record.
A colleague should be able to trust the recorded state without reconstructing a private email chain.
Key Configuration Requirements for Approval Gates
- Must Record Version Under Review
- Yes
- Must Retain Decision and Comments
- Yes
- Should Allow External Verification
- Yes
- Must Prevent Silent Escalation
- Yes
