Practical guide

Define your records before generating screens

Make fields, ownership and relationships explicit in the first app brief.

Last materially reviewed 2026-09-18

Quick answerA short record map prevents ambiguous forms, duplicate entries and confusing exports later.
What to know

Prepare record examples before setup

List the things the app needs to remember, such as a request and its status history. Give each field one fictional example and a reason for collecting it. Separate information supplied by a user from values the system should assign. Do not add a field merely because a template includes it. Unnecessary fields increase the amount of information you must validate, protect, explain and eventually remove.

What to know

Keep identity separate from appearance

A request’s title can change, so it should not be the only way to identify that request. Ask how a stable identifier will be preserved through edits and exports. If records relate to each other, write down that relationship in plain language: a status entry belongs to one request. Do not assume that two fields with similar labels will be connected correctly by the generated implementation.

What to know

Configure editing and ownership rules

For every field, decide who may create it, change it and see it. Include a correction example, such as fixing a mistaken date without changing the original requester. Decide whether closing a record hides it, archives it or removes it. These are product decisions with different consequences. Have a qualified reviewer assess sensitive record designs instead of treating a generated database as automatically appropriate.

What to know

Verify the map through an export

Create a few harmless records and inspect a supported export. Can you understand which record is which, how dates are represented and how related rows connect? Overskill documents table-by-table CSV export, so do not assume a single file will contain every relationship. Keep a small data dictionary with the brief. It will help the next maintainer understand the system without reverse-engineering field names during a failure.

Continue when useful

Next: Write form fields people can finish

Choose useful labels, examples and validation without collecting unnecessary information.

Open Write form fields people can finish →

Sources used for this page

These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.

  1. Overskill table-export documentation — Merchant documentation · overskill.com · Merchant-controlled · checked 2026-09-18
  2. OWASP Top 10 application-security awareness — Reference · owasp.org · Publisher independence not verified · checked 2026-09-18