frappe-doctype-design

name	frappe-doctype-design
description	Frappe DocType creation and form UX guidance. Use when creating, reviewing, or redesigning DocTypes, including field choice, tabs, sections, columns, required fields, naming, child tables, and form usability.

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.