Describe who you need to verify, which identity documents you accept, and how your team reviews them. Makeform turns that brief into an editable identity verification form with applicant details, document uploads, declarations, and an internal decision path.
Route verification requests to Slack, Google Sheets, and Zapier.
Sample prompts for the builder
Choose a complete brief, adapt the details, or send it to the Makeform builder. Each example shows a practical starting structure, not a completed verification decision.
Audience
Customers asked to confirm their identity for an account
Format
Multi-step request with document upload
Prompt size
635 chars
Example form structure
Multi-step request with document upload
Legal name, birth date, and contact
Current and previous address
ID type, issuer, number, and expiry
Upload the requested ID images
Applicant declaration
Suggested routing tags
Awaiting review
More information needed
Review complete
Ask for the document type and expiry date as separate fields. Reviewers can filter structured answers more reliably than notes buried beside an upload.
Step 1
Request
ask only for details and documents the review needs
Step 2
Submit
applicant provides structured answers and readable uploads
Step 3
Review
authorized staff compare fields and note discrepancies
Step 4
Resolve
record the outcome or request a specific missing item
Why structure matters
An identity verification form turns a loose email exchange into a repeatable intake. Applicants know what to provide, while reviewers see the same document facts, declarations, and decision fields each time.
Conditional questions can show the right upload slots for a passport, a two-sided card, or an alternate-document route. Applicants avoid irrelevant fields, and reviewers can see which rule produced the request.
Document type, issuing region, name as printed, and expiry date sit in structured fields beside the upload. That makes missing or inconsistent information visible before a reviewer opens every image.
Use reviewer fields for received items, match checks, discrepancy reason, follow-up owner, and outcome. The submission then records what was reviewed without suggesting that collection alone proves identity.
Adapt the workflow
Start with the closest use case, then replace its document list, retention wording, reviewers, and decision labels with your organization's actual process.
Connect an identity request to an application or account reference, collect the approved evidence set, and route incomplete submissions to an onboarding owner.
Pair contractor details with a sponsor, location, access dates, and ticket reference so the identity review stays connected to the access request.
Offer primary and alternate document paths, handle name differences explicitly, and keep reviewer checks tied to the membership application number.
Collect the account reference, requested change, and an established contact channel, then route discrepancies for a separate follow-up rather than promising an instant result.
Build the review path
The generator provides the field structure. Your organization decides what evidence it is permitted to collect, who may review it, how long it is retained, and what each outcome means.
Tell the builder who submits the form, why identity is reviewed, which primary or alternate documents are accepted, and whether each document needs one image or front and back images.
Edit the draft against your internal policy. Delete fields the reviewer does not use, make essential facts required, explain acceptable file quality, and add a contact path for applicants who cannot use the standard route.
Keep applicant questions focused on evidence submission. Put match checks, discrepancy categories, owner, dates, and outcome in a clearly labeled reviewer block so operational notes do not become confusing applicant instructions.
Send new submissions to the designated review queue. Use status labels such as awaiting review, more information needed, escalated, and complete, with a specific follow-up request instead of a vague rejection.
Choose the intake method
Email, a generic upload link, and a purpose-built identity verification form can all receive files. The difference is whether the document facts and reviewer decisions stay consistently attached to the request.
Field guide
A useful form collects enough information for a defined human review without turning every possible identity fact into a required question. These six sections keep the request specific and reviewable.
Person and request
Start with the identity details your review actually compares, then connect them to a customer, member, contractor, or application reference. A reviewer should know why the check exists before opening a document.
Document route
Turn your approved document list into clear choices. Conditional logic can request the right number of files and facts for each choice, while an alternate path prevents the form from silently excluding people who lack one common document.
Document facts
Do not rely on filenames or a general notes box. Structured facts let a reviewer compare the form with the image and quickly notice an expired document, an unexpected issuer, or a name that needs explanation.
Upload guidance
Place short instructions immediately above each upload. State which side is needed, whether the complete document must be visible, and which file types your team can open. Provide a correction route for unreadable files.
Declaration and notice
Tell the applicant why the information is requested, how to ask questions, and what happens next. Add an accuracy declaration, but avoid wording that claims the form itself establishes identity or guarantees a decision.
Reviewer outcome
A review block makes the operational result as structured as the intake. Use neutral status names and separate observed discrepancies from the final outcome so another authorized reviewer can understand what remains.
Related tools
Pair identity intake with onboarding, address checks, background-check requests, and flexible document collection using these live Makeform tools.
Collect customer and business information for an organization's own customer-review process.
Open toolRequest structured address details and the supporting evidence your address-check workflow uses.
Open toolCreate a simpler intake when the workflow needs files but not a full identity-review structure.
Open toolGather the service, contact, and account context that belongs before a client verification request.
Open toolCollect request details and routing information for a separately governed background-check process.
Open toolOrganize company, contact, and setup information for new vendors before internal review.
Open toolFAQ
Practical answers for operations teams designing an evidence request and review workflow.
An identity verification form is a structured way to request identifying details, accepted document information, and supporting uploads from a person, then record the review outcome. It can support a business process, but submitting the form does not by itself prove identity. Your organization still defines the evidence rule, reviewer responsibilities, exceptions, and decision process.
Common fields include legal name, contact details, a related account or application reference, document type, name as printed, issuing region, document number when necessary, expiry date, and clearly labeled upload fields. Add an applicant accuracy declaration plus reviewer-only fields for received items, match checks, discrepancies, follow-up, owner, outcome, and date. Remove anything your defined review does not use.
Yes. Add file-upload questions for the exact images or documents your process requests. Use separate labels such as passport identity page, card front, and card back rather than one unlabeled upload box. Put file-quality guidance next to each field and explain how an applicant can correct a missing or unreadable upload. Before publishing, confirm your organization's access, handling, and retention requirements for sensitive files.
Start with a multiple-choice or dropdown field listing the documents your organization accepts. Use conditional logic to show the facts and upload slots for the selected type: one image for a passport identity page, for example, or separate front and back fields for a two-sided card. If your policy permits alternate combinations, give that route its own clear fields instead of asking applicants to explain everything in notes.
No. The generated form organizes information and documents for your workflow; it should not claim that collection equals verification or approval. Define who reviews submissions, what comparisons they make, how discrepancies are escalated, and what each outcome label means. If another service performs a separate automated check, describe that step accurately and keep its result connected to the same review reference.
Work backward from the reviewer checklist. Keep a field only when a named step uses it, avoid asking for extra document images just because they might be useful later, and use conditional questions so applicants see only their evidence path. Include the applicable purpose and data-handling notice, restrict review responsibilities according to your internal process, and set retention practices before inviting submissions.
Yes. Duplicate or adapt the structure for each audience, but do not assume they share the same evidence rule. A contractor version may need sponsor, workplace, and access dates; a customer version may need an account reference; a member version may need an application number and alternate-document path. Separate forms often make the purpose, accepted documents, routing, and follow-up language clearer.
Yes. Makeform is unlimited free for generating, editing, publishing, and collecting responses with your form. The paid tier removes the Makeform badge. You can refine the generated field structure before publishing, including document choices, conditional paths, instructions, declarations, and reviewer fields.
Turn document requests into a defined review path.
