Case Intake Form
Use This When
Use this workflow when the frontend collects applicant, customer, borrower, seller, or policyholder details and creates a durable case.
What You Will Build
You will build intake that validates input, optionally runs quick screening, creates a durable case, and routes the user to a case workspace.
What Must Already Be True
- The app has browser-safe auth.
- The shared API Client exists.
- Required public configuration is available.
API Contract
Typical endpoints:
GET /api/v1/kyc/search
POST /api/v1/kyc-cases
PATCH /api/v1/kyc-cases/{case_id}/sections/{section_name}
Use quick screening before case creation only when it helps the product flow.
UI States
| Area | Required states |
|---|---|
| Form | Empty, invalid, ready, submitting. |
| Screening | Not run, running, evidence available, partial evidence. |
| Case creation | Saving, created, duplicate external ID, validation error. |
| Navigation | Stay on form for fixable errors, route to workspace on success. |
Implementation Steps
- Add Error States.
- Add Quick Screening when intake needs a first evidence pass.
- Add Create Durable Cases.
- Add Case Sections if intake saves additional sections after the case exists.
- Run Accessible Product States for form labels, validation, keyboard behavior, and focus handling.
Checkpoint
- Missing or invalid input is caught before submit when possible.
- API validation errors map back to the form.
- Duplicate external case IDs show a recovery path.
- Successful creation moves the user to the case workspace.
Common Mistakes
- Saving a durable case before the user has entered required identity context.
- Treating a quick screening result as the final intake decision.
- Losing form state when the API returns a validation error.
- Requiring an external case ID when the API can generate one safely.