Building an internal request app

Build an internal request app around one complete path: a staff member submits a request, someone takes responsibility, the requester sees progress, and the team records an outcome before closing. Agree on that path with the people who handle the work before configuring screens.

Choose one request type

Start with one kind of work, such as a facilities repair. Identify who may submit it, who triages it, who does the work and what counts as finished. A question may close when answered; a repair may need confirmation that the work is complete.

Sketch an ordinary case and an exception. A staff member reports a faulty meeting room light. The coordinator routes it to a worker, who records the outcome.

If the room is unclear, the coordinator asks for more detail. Decide who watches the request while it waits.

Create a record and submission form

Give each request a stable ID. A useful starting record includes the submitter, submission time, category, affected location or service, description, current status and person responsible for the next action. Add attachments or an urgency field only when the team has a rule for using them.

Ask the requester for facts they can know at submission. They should not have to guess the eventual owner or decision. Use categories that help triage, with a route for requests that do not fit. The companion guide to request form categories covers that choice in detail.

Build the form lifecycle

In a canvas app, give the form a clear mode for each task. New presents default values for creating a record; Edit loads an existing record so it can be changed; and View displays an existing record without allowing edits. This makes the difference between submitting a request and reviewing one explicit.

Connect the submission button to a save action. In Power Apps, SubmitForm can run from a button’s OnSelect behaviour formula. Before sending the record to its data source, it checks required fields, value constraints and the form’s overall Valid property, which combines the validity of its cards.

Configure the handovers

Use a short set of statuses with agreed meanings. Add a status only when it changes what someone should do or understand.

For example, Submitted means the record is confirmed and awaiting triage; Needs information means the requester has a question to answer; Assigned means a named person has taken responsibility; In progress means work has started. Closed means the closure rule has been met.

For each transition, specify who may make it and what happens to responsibility. A queue may receive a new request, but a coordinator must watch requests without a named worker. Reassignment should leave someone accountable throughout the handover. The assignment guide covers those rules; the status guide covers what the requester sees.

Statuses in Internal Request App: Purpose & Responsibility

Handle save results

Treat a successful save as the point when the workflow can confirm that the request exists. The form’s OnSuccess behaviour runs after a successful submission and its error properties are cleared; use that point for the confirmed-save response, such as showing the request ID and next step.

Give unsuccessful submissions a separate path. The form’s OnFailure behaviour runs if the save fails, and its Error and ErrorKind properties contain the failure information. Keep the person on the current form so they can respond to the error; an unsuccessful save leaves the form mode unchanged.

After a new record saves successfully, the form changes from New to Edit mode. That matters if the app lets someone correct a request after submission: the next save changes the existing record rather than creating another one. Make any correction action load the intended record before allowing an edit.

Record an outcome before closing

A closed request needs an explainable outcome. For a repair, record what was done and whether further work remains. For a declined request, record the decision and an appropriate reason. Asking for more information leaves the request open.

Decide who may record or amend the outcome and which details the requester may see. Keep internal notes separate if they need narrower access. The companion decision guide covers closure conditions and corrections to a wrong closure.

Check the configured app

Use fictional requests and accounts with the intended roles. Follow an ordinary request and one with missing information from submission through triage, assignment, outcome and closure. Compare each screen message with the saved record. Then check a mistaken category, an unavailable owner, reassignment, a wrong closure and an account that should not access the request.

Name a business owner for the workflow, a maintainer for the app and a route for correcting mistakes. Expand to another request type when its categories, responsibility and closure rules are equally clear.

Publish the workflow

Before staff can use a canvas app, save it outside the local environment and publish it. Save and publish again after changes that need to be visible to others. Give the app a meaningful name and clear description so staff can recognise its purpose when they find it in the app list.

When sharing the app, choose the intended staff users or a suitable Microsoft Entra ID security group. Also manage access to the data sources and any dependent flows, gateways or connections; sharing the app alone may not be enough for it to work as expected.