Creating DocTypes

A DocType is a kind of record. Creating one gives you a database table, a form, a list view, permissions, a REST endpoint, printing, reports, comments, attachments and a change history — without writing any code.

This page walks through creating one from scratch.

Do you actually need one?

Ask this first, because a new DocType is more work to live with than a field.

The test: if the thing has its own life cycle — created, edited and found independently of anything else — it is a DocType. If it only ever exists as a property of something else, it is a field or a child table.

Worked example

Throughout this page we build Fabric Test Certificate: a lab result for a fabric, linked to a Tech Pack, with a test date, a result and the certificate attached.

Step 1 — Create the DocType

1. In the Awesome Bar (Cmd/Ctrl + K), type doctype and open DocType List.
2. Click + Add DocType.
3. Fill in the header:

Step 2 — Add the fields

The Fields table is the body of the DocType. Add a row per field.

Each row has, at minimum:

• Label — what the user sees. Test Date.
• Type — what kind of data. Date.
• Name — the database column, filled in automatically from the label (test_date). Lowercase with underscores.

For our example:

Choosing the type

The Type decides how the value is stored, what the user sees, what validation runs, and how the field behaves in filters, reports and the API. The most common ones:

Field types covers all of them — what each is for, what goes in Options, a real GarmentFlow example of each, and which type changes are safe to make later.

Useful per-field settings

Each field row opens for more options:

• Mandatory — cannot be saved empty.
• Read Only — displayed, not editable. Combine with a script that computes it.
• Default — a starting value. Today works on Date fields.
• Unique — no two records may share the value.
• In List View — show as a column in the list.
• In Standard Filter — show as a filter box at the top of the list.
• Allow on Submit — editable after submit (submittable DocTypes only).
• Depends On — show the field only when a condition holds. Write eval:doc.result=="Fail".
• Fetch From — copy a value from a linked record. On a field next to a tech_pack Link, set tech_pack.model_name and it fills itself in.

Fetch From is worth learning early. It saves a script in most of the cases where people reach for one.

Layout

Fields render in the order they appear in the table. Drag rows to reorder. Insert Section Break to start a new block, Column Break to split a section into columns, Tab Break for tabs.

A form with three tabs and clear section headings is a form people fill in correctly. A flat list of twenty fields is not.

Step 3 — Set the naming

Naming decides what each record is called. Open the Naming section and pick:

For our certificate, a naming series is right: FTC-.YYYY.-.####.

Step 4 — Set permissions

Scroll to Permissions. A DocType with no permissions is invisible to everyone except the Administrator.

Add a row per role:

Two extras on each row worth knowing:

• If Owner — the permission applies only to records the user created.
• Level — for field-level permissions. Leave at 0 unless you are restricting specific fields; see Extending forms.

Step 5 — Save and try it

Save. Frappe creates the table immediately.

Open the Awesome Bar, type your DocType's name, and create a record. Everything works: the form, the list, search, filters, the sidebar, comments, attachments, the change history, and /api/resource/Fabric Test Certificate.

Child tables

A child table is a DocType with Is Child Table ticked. It has no list of its own; it only ever exists as rows inside a parent.

To add "several lot numbers per cutting order":

1. Create a DocType Fabric Lot Row, tick Is Child Table, and give it the columns you want (lot_number, metres, supplier).
2. Tick In List View on the fields that should show in the grid — child tables show only the ticked ones.
3. On the parent, add a field of type Table with Options = Fabric Lot Row.

For a GarmentFlow form, you add that Table field as a custom field rather than editing the parent DocType.

Submittable or not

Tick Is Submittable and records gain a state: Draft → Submitted → Cancelled, with a Submit button and locked fields after submit.

Use it when the record is a commitment other things depend on — the way Tech Pack and Production Batch are. Don't use it for masters and logs, where it just adds a step.

If you tick it, remember: any field that must stay editable after submit needs Allow on Submit.

Connecting it to GarmentFlow

Your new DocType is standalone until you connect it. Three ways, in increasing effort:

A Link field on your DocType — done already: tech_pack links each certificate to a style.

A link back from the Tech Pack form. Open Tech Pack via Customize, and in the Connections / Links section add a row with your DocType and the fieldname that points back (tech_pack). Certificates then appear in the Tech Pack's Connections tab.

On a workspace. Open the workspace you want it on, click Edit, and add a shortcut or link. Or make your own workspace for a group of custom records.

Moving it to another site

Because a Custom DocType is data, you can move it:

1. On the source site, open the DocType and use Menu → Export Customizations, or export the DocType record itself.
2. Import the resulting file on the target site.

Do this rather than rebuilding by hand — a rebuilt DocType with one differently-spelled fieldname will break every script and integration that referenced it.

Things that will bite you

• The name is permanent in practice. Renaming a DocType is possible but touches every reference. Decide the name before you save.
• Fieldnames are permanent too. Renaming a field leaves the old column behind and breaks scripts, reports and integrations pointing at it.
• Don't prefix with GarmentFlow's names. If you call yours Tech Pack Extra and we later ship a Tech Pack Extra, you have a collision. Use your company's prefix.
• Deleting a DocType deletes its data. There is no undo.

What to do next

Most needs are smaller than a new DocType. Read Extending forms for adding to what already exists, then Client scripts if your new form needs to react as it is filled in.