Troubleshoot a delegated approval screen

What this pattern solves

Search intent

Help a Power Platform builder understand when to use Power Apps Troubleshoot a delegated approval screen, how to implement it, and what mistakes to avoid before using it in a production business app.

Problem

Teams often need to troubleshoot a delegated approval screen but lose time recreating the structure, fields, decisions, and support notes from scratch.

What the finished pattern should include

• A maker can explain the control, formula, validation, and save behavior before release.
• The app gives users clear feedback for successful saves, missing values, and failed updates.
• The pattern can be handed to another builder without relying on hidden assumptions.

Solution

// Troubleshoot a delegated approval screen
// Use this as a screen/form state pattern.

// New button OnSelect
NewForm(frmRequest);
Set(varFormMode, "New");
Navigate(scrRequestForm, ScreenTransition.Cover);

// Edit button OnSelect
EditForm(frmRequest);
Set(varFormMode, "Edit");
Navigate(scrRequestForm, ScreenTransition.Cover);

// Save button OnSelect
If(
    frmRequest.Valid,
    SubmitForm(frmRequest),
    Notify("Review required fields before saving.", NotificationType.Warning)
);

// Form.OnSuccess
Set(varSelectedRequest, frmRequest.LastSubmit);
Notify("Request saved successfully.", NotificationType.Success);
Back();

// Form.OnFailure
Notify("Unable to save request: " & frmRequest.Error, NotificationType.Error);

Implementation checklist

• Confirm the Power Apps scenario and the business user this pattern supports.
• Identify the data source, owner, security model, and exception path before building.
• Build the smallest reusable version first, then add optional branches or polish.
• Test with realistic data, permissions, edge cases, and handoff expectations.
• Link this pattern to its collection, topic hub, and related implementation patterns.

Step-by-step instructions

• Add the controls, variables, and data source references needed for Troubleshoot a delegated approval screen.
• Validate required fields before running Patch, Collect, or SubmitForm logic.
• Wrap the save behavior in IfError so users see success and failure feedback.
• Test with a new record, an existing record, blank optional values, and a failed connector call.

When to use

• Use when the organization needs to troubleshoot a delegated approval screen as part of a repeatable process.
• Use when the solution should be understandable by both builders and business owners.
• Use when consistency, supportability, and governance matter more than a one-off workaround.

When not to use

• Avoid when the workflow is temporary and does not need reusable structure.
• Avoid when an existing enterprise system already governs the process end to end.

Common mistakes

• Starting with automation before the business rule is agreed.
• Using unstructured notes where structured fields are needed for reporting.
• Skipping the exception path until users find it in production.

Troubleshooting

• If reporting is weak, identify which values need to become structured fields.
• If adoption is weak, simplify the next action and remove unnecessary choices.

FAQ