frappe-doctype-design

Design every DocType as a human-facing form, not a flat database table.

Before adding fields, identify:

• the DocType's purpose and primary user
• the real business process or lifecycle it supports
• the relationships, status, reporting, and search needs
• whether it is master data, a transaction, a child table, or a configuration DocType

Field discipline:

• Add only fields that are required for identity, workflow, relationships, decisions, audit, reporting, or search.
• Do not add speculative, vanity, duplicate, or generic fields unless the use case clearly needs them.
• Make required fields truly required, not merely convenient.
• Use child tables only for real one-to-many repeating data.
• Prefer human-readable labels and stable snake_case fieldnames.

Form layout:

• Do not dump all fields into one tab or one section.
• Use Tab Break for major mental models only when the form has enough fields to justify tabs.
• Use Section Break for logical groups inside a tab.
• Use Column Break to create balanced, scan-friendly rows.
• Put the title, status, primary links, and most common required inputs first.
• Put advanced, rare, admin, or integration fields later, and fold them when appropriate.
• Avoid empty tabs, thin sections, and layout breaks that exist only for decoration.

Useful tab patterns include:

• Overview for identity, status, and primary summary fields
• Details for the main business data
• People or Parties for owners, customers, suppliers, employees, or contacts
• Schedule for dates, timelines, reminders, or recurrence
• Finance for amounts, accounts, taxes, or pricing
• Settings for infrequent configuration
• Activity or Audit for comments, references, or system-facing traceability

When proposing or creating a DocType, present the layout grouped by tab and section, and explain why each group exists. If a requested field does not belong, call it out and omit it unless the user confirms the need.