When ERPNext custom fields and Customize Form are enough
A team that needs one or two extra data points on invoices, items or customers can usually add them without forking ERPNext. Customize Form is the desk tool for this: it opens a standard DocType, such as Sales Invoice, Item or Customer, and lets an administrator add *custom fields* to it and change the behaviour of existing fields through *property setters*. A custom field is stored as metadata in the database, not as code in the ERPNext source tree, so the standard app stays untouched. Before building anything, list the fields you need, the DocType each belongs to, and who enters the value. Then check whether the value already exists on a linked master, because a field that fetches from a Customer, Item or Address often covers the need without any manual entry.
Changes made through Customize Form remain in the site database, so they survive normal ERPNext updates in most cases, but they are not version controlled by default. That creates two planning items. First, the customization must be reproduced on every environment (test, staging, production), either by repeating the steps or by exporting it, which is covered in the sibling topic on fixtures. Second, a property setter can override a standard field attribute such as whether a field is mandatory, so each upgrade needs a review of what changed. Confirm with the Frappe documentation for your exact version how custom fields, property setters and any field-level exports are handled during migration, and test that path on a copy of your site before the production upgrade.
Stop using Customize Form when the requirement is logic, not data. If a field must be calculated from several inputs, validated against business rules, or should trigger a notification or an external call, the work moves to client scripts, server scripts or a custom app, each with its own permissions and deployment considerations. Server scripts also depend on the server_script_enabled setting from version 15 onward and are not available on Frappe Cloud public shared benches, so check that before choosing that path. A useful test: if the answer to a field question is a yes or no decision plus a formula, or it needs a new screen or report, plan it as code and budget for review and testing, not as one more field.
Field types and form changes compared
This table compares the main no-code ways to change an ERPNext form: custom fields, fetch-from values, property setters and display overrides. Read each row by what the change alters, where it applies and when it fits, then check the options against the ERPNext version you run, since field types and Customize Form behavior change between releases. The main takeaway is that most layout and validation changes stay in the database and can be exported, while logic that needs code belongs in a script or app.
| Change | What it alters | Where it applies | When it fits |
|---|---|---|---|
| Custom field | Adds a new field to a DocType, such as a Data, Select, Link or Table field | Only the DocType you customize, with its own insert position in the form | A business attribute ERPNext does not store, such as a project code or approval reference |
| Fetch from | Copies a value from a linked master into the current document when the link changes | A Link field pointing to a master record, such as customer group or item group | Reference data that should stay consistent with the master and not be retyped |
| Property setter | Changes an existing property of a standard field, such as label, default, options or mandatory flag | One field on one standard DocType, stored as an override | Small adjustments to standard behavior, such as making a field mandatory or changing a default |
| Read-only or hidden override | Makes a standard or custom field read-only, hidden or conditionally shown using depends-on rules | Per field, with conditions that can reference other field values | Preventing edits after a status change or hiding fields irrelevant to a document type |
| Permission-based hiding | Restricts field visibility by role through permission settings, not layout | Per role across the DocType, including field-level permissions where available | Sensitive fields that some users must never see, such as cost or margin data |
| Client script or server script | Adds logic beyond what properties can express, running in the browser or on the server | Form events or server events, subject to the server script enablement setting | Conditional calculations or validations that properties cannot describe |
| Custom app override | Changes DocType behavior or controller logic through code shipped in an app | Any document or method the app hooks into, deployed with version control | Changes that must be tested, versioned and reproduced on every environment |
How to add a custom field and verify it
This sequence takes a team from an agreed field requirement to a custom field that is created, populated, visible in the right views and tested on a non-production site. Each step ends with a check that confirms the change before the next one starts.
Confirm the target DocType and field requirement
Identify the standard DocType the field belongs on, such as Sales Invoice, Item or Customer, and write down the field label, the data it holds, who enters it and which downstream documents or reports need it. Check whether a standard field already covers the need, because duplicating an existing field creates two sources of truth. Done when the requirement is written and signed off by the business owner of the process.
Create a test site and copy the data
Create a separate ERPNext site on the same version as production, restore a recent production backup or a representative subset of records, and confirm that the site loads and that the target DocType has sample documents. Do not make the change on production first. Done when a test user can open a sample document on the copy and the data matches what the team expects.
Add the custom field through Customize Form
Open Customize Form for the target DocType, or open the Custom Field list and add a new row, then set the label, fieldname, fieldtype and options. For Select fields, enter one option per line. For Link fields, set the options to the target DocType. Save and reload the form. Done when the field appears in the form layout at the position you set and the saved fieldname matches the naming standard your team uses.
Configure fetch from a linked master
For a Link field that should pull a value from a master record, such as a Customer Group or Territory from the linked Customer, add a second custom field of the target type and set its Fetch From property to the link field name followed by the source field, for example customer.customer_group. Confirm that the fetched field is read-only or that you have deliberately allowed edits. Done when selecting a linked record fills the fetched field on a new draft document without a manual save.
Verify the field in list, report and print views
Add the field to the list view settings and check that it shows on the list page. Open Report Builder on the DocType and confirm the field can be selected as a column and filter. Open a print format for the document and confirm the field is present, or add it to the print format if it should appear. Done when the field values display correctly in all three places for both new and existing documents.
Test permissions, validation and existing records
Log in as users with the roles that will edit and read the document, then confirm that they can see and change the field only as intended. Test any mandatory or validation setting with a blank and a valid entry. Confirm that existing documents without a value behave correctly when opened, saved and submitted. Done when a short written test list passes for each role and the results are recorded.
Record the change and plan the move to production
Document the field name, type, options, fetch setting, the views where it appears and the test results. Decide how the customization will be exported and reapplied on future upgrades, for example through exported customizations, and confirm this with your implementation partner or internal owner before production. Apply the change to production only after the test results are approved, then repeat the list, report and print checks there. Done when the production record shows the same behavior as the test site.
How fetch from linked masters keeps data consistent
A custom field of type Link can be paired with a fetch-from expression so that ERPNext copies a value from a linked master, such as the customer's territory, the item's default warehouse or the supplier's currency, into the transaction when the user selects the link. The expression points at a field on the linked record, written in the form link_field.target_field, and the copied value is stored on the document itself. That stored copy is the important detail: the transaction does not read the master again each time it is opened. Before you rely on this pattern, decide which master fields are stable enough to copy, and confirm in your own version how the fetch behaves when the link is changed on a draft, since the behavior around fetch-from fields has been refined across releases.
The timing difference matters most. On a draft, a fetched value is refreshed when the link changes, so a user who corrects the customer on a quotation will see the new territory or tax category appear. Once a document is submitted, the fetched value is locked along with the rest of the record, and a later edit to the customer master does not flow back into the sales invoice, delivery note or purchase order. That is usually the correct accounting behavior, because the posted document should reflect what was true at the time of the transaction. It can still surprise finance and sales teams who expect a master correction to show up everywhere, so document which fields you intend to be point-in-time snapshots and which should be read live from the master through reports.
Test the edge cases with your own master data, not a demo dataset. Change a master field after a draft has been saved, after a submission, and after a cancelled and amended document. Check the fields that drive tax, pricing, warehouse and currency, and confirm they match the business rule you agreed with the controller. Include masters with blank values, masters that were renamed, and items with multiple default warehouses, because blank or ambiguous sources often produce empty fetched fields without an error. Record the results in a test script so the same checks run again after every upgrade or customization change.
What survives ERPNext upgrades and what needs review
Customizations made through Customize Form and custom fields are stored in the database, so they usually carry across a version change, but they still depend on standard fields, names and print templates that the new release may alter. Each card below is a category to check after every upgrade, with the release notes for your target version and the supported versions policy as the reference point.
Custom fields and their placement
Custom fields you add through the Customize Form tool are stored as records in the database rather than in your code, so they normally persist through an upgrade. Confirm that each custom field still exists, keeps its type and sits under the expected section after migration. Check also that any field depending on a standard field's label or position still resolves in the new form layout.
Property setters and changed defaults
Property setters override attributes of standard fields, such as mandatory status, read-only state, default values, hidden flags and options. An upgrade can change the standard field these setters target, or the core default they were correcting. Review every property setter against the new standard definition and remove any that now duplicate the default or no longer apply.
Standard field renames and removals
When a standard DocType field is renamed or removed, custom fields that point to it through *Fetch From* expressions, link filters or client-side logic can break silently. Compare the field list of each DocType you customized against the release notes for your target version. Treat any renamed or removed standard field as a blocking item until every dependent custom field and script has been updated.
Print formats that reference fields
Print formats built on Jinja HTML reference field names directly, so a renamed or removed field can leave an invoice or delivery note with blank values or a rendering error. Custom fields you added to a print layout also need a visual check, because text length and page breaks can shift. Print a sample of each customized document type after the upgrade and compare it with the approved layout.
Client and server scripts that read fields
Client scripts and server scripts reference fields by name in event handlers and API responses. A field rename or a change in event timing can stop a script from firing or make it return unexpected values. Server scripts also depend on the server_script_enabled setting from version 15 onward, so confirm that setting on the target site before testing. Keep a list of scripts with the fields each one reads.
Records that live outside version control
Customizations made in the UI exist only in your database unless you export them. Before an upgrade, take a backup and record every custom field, property setter and script in a change log so the state can be reproduced on a staging copy. Assign an owner to test the upgrade on staging with a copy of production data, and keep the release notes and the supported versions policy on hand for sign-off.
Permissions and data risks in custom fields
A custom field is only as safe as the form, print format and report it appears on. The cards below cover who can make changes, how a new field inherits access, where sensitive values can leak outside the form, and how to trace what changed. Confirm the role model in your own environment before the first field is added.
Who can create fields
Adding a custom field or opening Customize Form is an administrative action, and in most ERPNext setups it sits with the System Manager role. Some organizations also grant customization permissions to a narrower group, so check which users hold the System Manager role and whether any other role can open the Customize Form tool. Treat that list as part of your change control, not a side detail of the build.
Field permissions follow the DocType
A new custom field does not get its own access rules. It is visible and editable wherever the parent DocType's permissions allow, so a field added to a sales document can be read by every role that can read that document. Review the DocType's role permissions after each change and confirm whether any field should be hidden from roles that can see the rest of the record.
Sensitive values on print formats
Print formats and PDFs expose fields that a user might never open on screen. A custom field holding a tax ID, bank detail or internal cost note can end up on a customer-facing invoice or delivery note if the print format includes it. Before go-live, compare every print format and report that uses the DocType against the list of fields flagged as sensitive, and confirm who receives each generated PDF.
Reports and exports widen exposure
Report Builder, query reports and list exports can pull any field a user is allowed to read, and a custom field added later may appear there without anyone reviewing the report. Check whether the roles that run reports can export the DocType, and test a sample export with a non-administrative account. This is where a field that seemed internal often becomes visible to a wider group.
Logging customization changes
Record who created or altered a field, when, and what the property changes were. Version tracking on DocTypes and the activity log can show document-level edits, but you should confirm whether they capture changes to form customizations themselves. If they do not, export customizations to version control so each change is reviewed and traceable through commits.
Confirm the role model first
Before building, write down which roles may create fields, which may edit property setters, and which may view each sensitive DocType and its outputs. Test the plan with a user for each role on a staging site. Your auditors and data owners should sign off on this matrix, since ERPNext's permission behavior depends on your roles, company restrictions and any custom apps already installed.
Questions teams ask before adding custom fields
What drives the cost of adding custom fields to ERPNext?
The cost depends on how many fields you add, where they appear, and how much logic sits behind them. A single text or link field on one form is a small change, while fields that fetch values from linked masters, feed reports, print formats or downstream automation take more design and testing. Costs come from three places: the business analysis to agree what each field means, the configuration and testing on a non-production site, and the documentation and handover. Ask any quote to list each field, the forms it touches, the reports and print formats it affects, and who tests it. Also ask whether the work is one-time or includes ongoing support after upgrades.
How long does a typical custom field change take?
Duration depends on the number of fields, the number of forms and roles involved, and how many approvals the business needs before the change goes live. A simple field on one DocType with clear requirements moves quickly, while a set of related fields that must match reports, permissions and print formats needs more review cycles. No standard duration applies across organizations, so ask for a timeline in the written scope that separates requirements, build and test on a staging site, and production release. Your own change board may add time, and that should be planned in, not treated as a surprise.
What does our team need to provide for a custom field project?
The work moves faster when business owners are available and a test site exists before anyone edits a form. You need named owners from finance, stock or operations who can confirm what each field stores and who may read it, a staging site that mirrors your production version, and sample data that reflects real records without exposing sensitive customer information. Provide a list of the reports, print formats and integrations that read the forms being changed. Without these, teams often discover late that a field breaks an export or an approval step.
Can our internal staff add custom fields without outside help?
Yes, a System Manager can add many custom fields through the Customize Form tool and the Custom Field list without writing code, and small teams often start this way. The risk lies in what the change touches: property setters, fetch-from settings and permissions can affect data entry, reports and integrations in ways that are not obvious from the form alone. Internal staff should test on a copy of production, document each change, and record who approved it. If the team lacks time or someone to review changes, a partner can take on the design and testing while your staff keep ownership.
Do custom fields survive ERPNext upgrades?
Custom fields stored as Custom Field records generally persist through upgrades because they live in the database, but property setters and changes to standard forms need checking after each major version. Frappe's supported versions page lists which versions receive support, and an upgrade is a point to review every customization against release notes. Export your customizations to version control so you can reapply or compare them. Confirm the exact upgrade behavior against the release notes for your target version before you plan the change.
When should we move from custom fields to a custom app?
Move to a custom app when the change needs code rather than configuration, such as new DocTypes with validation logic, server-side behavior across several forms, or features you want to version, test and deploy like software. Custom fields are a good fit for extra data on existing records, but once you need several fields to work together with scripts, reports and integrations, a custom app gives you version control, code review and a repeatable deployment. Server scripts are another option for small logic, but they are disabled by default from version 15 and must be enabled. Ask your partner which layer fits each requirement.
What risks should we check before changing a standard ERPNext form?
The main risks are broken data entry for users, incorrect values in accounting or stock records, and reports or integrations that stop receiving expected fields. A field marked mandatory can block transactions, and a fetch from a linked master can overwrite values if the source changes. Check permissions for each role that sees the field, test how submitted documents behave, and confirm that exports, print formats and API consumers still work. Keep a rollback plan and a record of every property setter so you can reverse a change quickly.
How DeployOpen scopes custom field work
DeployOpen writes the scope for custom field work before any build starts, so the client knows exactly what will change in the ERPNext forms, why it changes, and how it will be checked. A written scope lists each new field with its fieldtype, the DocTypes it lands on, the link fields it depends on, every fetch-from rule that copies values from linked masters such as Customer, Item or Supplier, and each Property Setter that changes a standard field's label, default, visibility, read-only state or options. It also names the test cases that prove those rules behave correctly for each role, and the upgrade checks that will be rerun when the ERPNext minor or major version changes. Teams that skip this list usually discover later that a fetch rule overwrites a value on submitted documents or that a Property Setter hides a field a report depends on.
The scope should also state where each change will live. A field created through Customize Form is stored in the site database, while a field that must be versioned goes into a custom app or a fixtures export. Ask the partner to name the decision for every item, the owner of the change, and the environment where it is first tested. DeployOpen can deliver this work as a fixed-scope engagement with a written list of deliverables, or as a retainer for teams that keep adding fields as the business changes. Under a retainer, the scope still needs a written baseline, and each new request should be recorded against it with its test cases and upgrade impact.
Costs follow from the number of changes, how many DocTypes and roles they touch, how many test cases the business needs, and how often the site is upgraded. The one-time part covers analysis, build, testing and handover. The recurring part covers re-testing after each upgrade and any new fields requested later. When you request a quote, ask for the price per item and for the test and upgrade checks separately, so you can see what is included and what would be added if a requirement changes. Confirm with your own administrators which custom fields must survive an upgrade and which can be rebuilt, because that answer, not a generic estimate, determines how much upgrade work the scope needs.
