# Application intake and internal review

Canonical: https://useformwork.com/use-cases/application-review

Updated: 2026-09-17

Collect applications with conditional questions, organise internal review data, and preserve the form version behind each response.

An application process usually needs more than a submit button. Respondents provide information, staff check it, and the requirements change over time. FormWork supplies configurable forms, internal metafields, workflow steps, and entry history for building that process.

This walkthrough describes a configuration pattern. It is not an automated eligibility decision system or a prebuilt approval product.

## Define inputs and checks

Build the application from typed fields, conditional sections, and any repeated details. Use [server-side validation](/product/server-side-logic) to require the information relevant to a respondent's answers. For supporting documents, use the [file upload fields](/docs/entries/files-uploads).

Preview both complete and incomplete applications. Include boundary cases: an empty repeated group, a changed answer that hides a section, and a failed workflow request.

## Add a staff review form

Configure a [metafield form](/docs/entries/metafields) with a review status, reviewer notes, and a next action. Staff can work with those internal answers alongside the applicant's entry. Use [views and filtering](/docs/entries/views-filtering) to organise the work that needs attention.

Do not equate the Standard role with a restricted reviewer role. Permissions operate across an account, and Standard members can work with account resources. Review the [permission model](/docs/platform/users-permissions) before deciding who should have access.

## Make downstream actions observable

A workflow can react to configured events, evaluate conditions, and call an external API. Inspect [workflow runs](/docs/entries/workflow-runs) to check the outcome. A failed workflow does not necessarily stop the original submission or update, so define how staff should handle failed handoffs.

## Change requirements without rewriting history

Publish revised questions and workflows as a [new form version](/product/versioned-forms). Old entries stay pinned to their original version, including entries that were already in progress. [Entry revisions](/docs/entries/revisions) separately show changes to the answers.

## Define completion for your team

An application is operationally complete when the required information is present, the review state is clear, and necessary handoffs have succeeded. Configure those checks for your process; the platform does not infer your organisation's approval policy.

Explore [product capabilities](/product), [monthly plans](/pricing), or [discuss your requirements](/#contact).