ERPNext web forms for customers and suppliers

When ERPNext web forms fit customer, supplier and applicant intake

A web form in ERPNext lets an outside party, such as a customer, supplier or job applicant, enter data that is saved as a record in a DocType without holding a desk login. The form is shown on a public or portal page, validates what the visitor types, and writes the result back into ERPNext as a document that your staff then review and act on. That is the right fit when the person sending data has no reason to see anything else in your system, and when the data arrives in a predictable shape that maps to fields you already maintain.

The three intake cases most teams start with are customer onboarding, where a prospect submits company details, tax identifiers and billing contacts for a Customer record; supplier registration, where a vendor provides banking, tax and certification details for a Supplier record; and job applications, where a candidate submits a profile and attachments against a job opening. In each case the form writes to a standard DocType, so the record appears in your normal lists and workflows. Decide up front which fields the outside party may set, which are filled by your team after review, and whose approval turns a submission into an active master. Supplier bank details and tax IDs deserve particular care, because a form that is open to guests can receive changes from anyone who finds it.

Web forms are a configured feature. You define the form, its fields and its success message in the desk, without changing ERPNext source code or deploying a custom app, so changes can be made and reviewed by someone who understands the business process. The trade-off is scope. A web form handles one entry action well, but it does not give a counterparty a persistent account, a history of their documents or a self-service view of their orders and invoices. For that, you would use the portal and its list views, and for logic that a form cannot express, a custom app. Confirm the exact form options available in your ERPNext version against the ERPNext GitHub repository before you commit to a design.

Login or guest web forms: which audience each one serves

Login-required web forms are open only to users who have signed in to the ERPNext portal, typically customers, suppliers or contacts that already exist as user accounts. The submitted record is linked to that signed-in user and, where the form is designed for it, to the customer or supplier they belong to. This makes the record traceable and lets you rely on the existing login policy, such as password rules and two-factor authentication, instead of inventing a new trust mechanism. The trade-off is that every submitter needs an account, which someone must create, invite and later deactivate.

Who submits: only active portal users whose roles allow access to the form and the DocType behind it.
Identity on the record: the owner and the linked party are taken from the logged-in user, so audit trails show who entered the data.
Account lifecycle: someone must provision, review and disable these accounts when customers or suppliers leave.
Login policy: the sign-in controls you already run for ERPNext, including any single sign-on or LDAP setup, apply to these submitters.
Abuse exposure: lower, because a bad actor needs valid credentials first, but compromised portal accounts become the main risk.

Confirm with your security team how portal accounts are created, whether they use your identity provider, and how quickly access is removed when a partner relationship ends.

Web form configuration options and when each fits

This table compares the main settings on an ERPNext web form and what each one changes for the outside submitter and for the internal team. Read each row as a decision: find the situation you have, then check what the setting exposes and what your back office must handle afterwards. Most risk sits in the login requirement and the DocType choice, so settle those two first.

Setting	What it changes	When it fits	Back-office effect
Target DocType	Selects the record the form creates, such as a Lead, Supplier Quotation or Job Applicant	Pick the DocType that matches the process the outsider starts, not a generic one	Records land in standard workflows, so staff see them in familiar lists and reports
Login required	Guest submitters can use the form without an account; logged-in users are tied to their own records	Guest forms suit public enquiries and applications; login suits existing customers or suppliers	Guest submissions need spam and validation controls; logged-in submissions carry an identity you can trust
Allow edit after submit	Lets the submitter change a record after it is sent	Useful when the submitter must correct details before staff act on them	Staff may see values change after review, so define a cut-off point in the process
List view for portal users	Shows submitters their earlier entries in a portal list	Fits repeat customers or suppliers who track requests and documents	Relies on portal permissions; confirm each user sees only their own records
Field selection	Chooses which fields appear on the form and which are required	Expose only what the outsider must provide, then fetch internal values in the back office	Fewer fields reduce bad data but may leave staff to complete gaps later
Redirect and success message	Sends the submitter to a chosen page or shows a confirmation after saving	Use a message for simple forms; use a redirect to a thank-you or status page for portal flows	Confirm the message sets expectations on response times, which your team must then meet
Custom scripts	Adds browser-side or server-side logic to the form, such as validation or lookups	Use when a field rule cannot be expressed in settings alone; confirm the scripting option your version supports	Scripts become code to maintain and test through upgrades; server scripts may be disabled on some hosts

Which DocTypes to expose and which to keep internal

Web forms can only collect what an outside user is allowed to see and submit, so each DocType needs an explicit decision before the form is built. The cards below separate the records that suit outside users from the accounting and stock documents that should stay internal, and flag the linked masters and fields that can leak information if they are exposed by accident.

Intake DocTypes that suit outside users

Customer, Supplier, Issue and Job Applicant are the usual candidates because they capture a party's own details or a request, not a financial position. Each one is a single record created by the outside user and then reviewed by staff. Confirm that the form creates a new record only and that outside users cannot read other customers' or applicants' rows. Check this against your own role setup in a test site before go-live.

Accounting documents stay internal

Sales Invoice, Payment Entry, Journal Entry and General Ledger entries reveal balances, pricing, margins and payment history, and they carry tax and posting logic that outside input should never drive. Keep these DocTypes out of web forms entirely. If customers need to see invoices or statements, provide them through portal pages or reports with explicit permissions, not through a form that writes to the ledger.

Stock and purchasing documents need review

Purchase Orders, Material Requests and Stock Entries change quantities, valuation and supplier commitments. A supplier form may be safe for profile updates, but it should not create purchase documents that post directly. Route submissions to a draft or to a review queue, and confirm which fields on each document a supplier can set before any form is published.

Linked masters can leak internal data

A web form field linked to a master such as Item, Price List, Account or Cost Center can expose the list of values to outside users if link permissions are too broad. Pricing, cost centers and internal account names are often sensitive. Limit each link field to the values the outside user needs, and test the dropdown while signed out or as a portal user to see what appears.

Internal fields must stay off the form

Fields such as owner, assigned user, internal notes, rates, credit limit, default accounts and status workflow values should never appear on an outside form, even as hidden fields. Hidden fields can still be posted and overwritten from the browser. Remove these fields from the web form layout and confirm the form cannot set them by checking the saved record after a test submission.

Applicant data needs its own limits

Job Applicant records include personal data, CVs and recruitment status. Decide which fields a candidate can enter, who can read the submission, and how long records are kept. Confirm the retention rule with your HR and legal teams, and review access for recruiters and hiring managers separately from general staff, since applicant data carries a higher privacy burden.

How to set up a web form and verify it before go-live

This sequence takes a web form from a chosen DocType to a tested portal experience, so each step ends with a check that the right users can submit, see and edit only their own records before real customers, suppliers or applicants use it.

Choose the DocType and scope the fields
Start by deciding which DocType the form writes to, such as Customer, Supplier, Job Applicant or a custom DocType you own. Owner the decision in writing with the business team, and list every field the outside user will fill in. Mark the fields that are internal only, such as credit limit, default accounts, pricing and status, because they should stay off the form. The step is done when the field list is signed off and each internal field has a named reason for being excluded.
Create the web form against the DocType
In the desk, create a Web Form, link it to the chosen DocType and add only the approved fields in the order you want them shown. Set the route, title and the success message the user will see after submission. Keep the form in a draft state until the access rules in the next step are final. The output is a saved Web Form whose field table matches the scope list one for one.
Set login, edit and owner rules
Decide whether the form accepts guests or requires login. Login-required forms let users see and edit only what they created, while guest forms need careful review because anyone with the link can submit. Confirm whether users may edit submitted records and whether they can see the list of their own submissions. Check that the owner of each new record is recorded as expected. Done when the login setting, edit setting and list setting match the written decision from the first step.
Configure list and detail views for portal users
If portal users need to return to their submissions, configure the list view and the detail view so they show only the fields the user needs. Review the list columns and the detail page for internal fields, linked document names and comments that could expose other parties' data. Confirm that linked masters such as Territory or Price List do not reveal internal information through their dropdown values. The check passes when a sample record, viewed as the portal user, shows only the approved fields.
Test as a guest and as a portal user
Run the form in a private browser session without login, then in a second session as a portal user who did not create the test record. Submit valid data, submit invalid data to confirm validation messages, and attempt to open another user's record by changing the URL. Repeat with a user who has the role required for internal review, if your model includes one. Record each result in a test log. Done when every expected allow and deny outcome is recorded and matches the access rules.
Verify the records and hidden field exposure
Open each record created by the tests in the desk as an administrator. Confirm the owner, the creation time, the linked masters and the default values filled in by the system. Compare the saved record with the form submission to make sure no internal field was set from the outside, and check the browser network responses and page source for hidden or internal field names. The output is a short verification report listing any field that leaked or was writable when it should not be.
Clean up test data and confirm go-live
Delete or archive the test records and any test users, then confirm the Web Form is published only after the verification report shows no open findings. Ask the team that owns the DocType to confirm the downstream workflow, such as notifications or approvals, works with the live records. Keep the test log and the access decision with the change record so later changes to the form can be checked against the same tests.

How permission checks apply to portal users and guests

Web form access is separate from desk role permissions. A web form decides whether a visitor can open and submit a form, but it does not grant that visitor any desk permission on the DocType behind it. What a portal user sees in a list view or on a detail page is decided by the permission rules on the target DocType: role permissions, user permissions that restrict records to a customer, supplier or other linked value, and sharing of individual documents. Guest access adds a further layer, because a guest has no user identity to match against those rules. Before you publish, confirm for each DocType whether the portal user role has read access at all, and which user permissions narrow the records it can see.

Test every form and list view with real portal accounts, not with an administrator who is impersonating a customer. Create one account per audience, such as a customer contact, a supplier contact and an applicant, link each to the correct master record, and check that they see only their own documents, that they cannot open a sibling record by changing the URL, and that the submitted data appears where they expect. Repeat the test after any change to user permissions, sharing or the form itself, since those changes can widen access without any visible error.

Review every field that appears in the list and detail pages, not only the fields on the form. Linked fields can expose the names or addresses of records a portal user should not see, and totals, status fields and comments can reveal internal pricing or workflow state. Ask the business owner to sign off on each visible field for each audience, and record the decision. Confirm the exact behavior of your ERPNext version against the documentation before you rely on it, because portal and permission behavior has changed between releases.

Security and operational risks to plan for

Public forms widen the attack surface of an ERP that holds accounting and stock data. The risks below connect because each one depends on how the form, its DocTypes and its notifications are designed together, and each needs a named control before the form opens to outside users.

Spam and submission abuse

Guest forms accept submissions from anyone who can reach the URL, so bots can flood the DocType with junk records and fill inboxes with notifications. Plan rate limiting at the reverse proxy or web application firewall, a captcha or equivalent challenge where your policy allows it, and a review queue so no record reaches accounting or stock until a staff member has checked it. Ask the partner or your own team to test submission volume before launch.

Exposing fields by mistake

A web form only shows the fields you add to it, but the underlying DocType may hold prices, credit limits, cost centers or internal notes. Build a field list for each form and review it against the DocType's permissions for the portal or guest role. Test the form as an outside user and confirm that no linked master data, such as customer groups or price lists, appears in dropdowns or the list view.

Attachment handling

Uploaded files from outside users can contain malware, oversized content or sensitive documents that belong in a restricted folder. Decide which file types and sizes the form accepts at the web server and within ERPNext, who can view attachments after submission, and how long files are kept. Confirm how attachments are stored and backed up in your infrastructure before you open the form to customers or applicants.

Internal email notifications

Each submission can trigger an email to a shared inbox or a staff member, and those messages can carry field values into mail systems you do not fully control. Define which fields appear in notifications, who receives them, and whether a notification should contain a link that requires a login instead of the data itself. Test the sending address and reply-to settings so replies from outside users do not reach the wrong team.

Custom scripts on public pages

Client and server scripts attached to a form can run for anonymous visitors, which makes any logic that reads or writes records a risk. Server Scripts run Python on document events or as API endpoints, and from version 15 they are disabled by default and must be enabled with the server_script_enabled setting. Keep public form logic minimal, review each script's permissions, and confirm that the hosting option you choose allows the scripts you need.

Keeping forms aligned after upgrades

Web forms, their field lists and their portal permissions can drift from the DocTypes they depend on when ERPNext or a companion app is upgraded. Keep form definitions in version control, record which fields and permissions each form relies on, and retest every public form after each minor or major upgrade in a staging site. Plan this as recurring work, because supported versions change on fixed dates and each release can alter behavior.

Questions buyers ask before outsourcing web form work

What does outsourcing ERPNext web form work cost, and what drives the price?

The price follows from a written scope, so no figure is given here. The main cost components are discovery (which DocTypes to expose and what each field means), design of the form layouts and validation, permission and portal testing, and handover. Costs rise with the number of forms, the number of approval steps, integrations with other systems, and how many user groups must see different data. Costs are one-time for the build, while hosting and any later changes recur. Ask for a quote that lists each form, its audience (guest or logged-in), the DocTypes it writes to, and the test cases included.

How long does it take to design and test a set of ERPNext web forms?

Duration depends on how many forms there are, how settled the DocType decisions are, and how many approval or permission rules apply. Simple guest forms that create one record usually move faster than login forms that show a customer or supplier their own list of documents, because the permission checks need separate testing. Ask the partner for a timeline in the written scope that separates design, build, permission testing and user acceptance, and confirm which of these the internal team must sign off.

What must our internal team provide before a web form build starts?

Your team needs to supply decisions the partner cannot make for you. These include which DocType each form writes to, the exact field list with types and mandatory flags, which values come from linked masters such as customers or suppliers, and who approves a submission and under what rules. You also need to name the business owner who accepts the forms, and decide what external users may see after they log in. Missing answers at this stage are the most common cause of rework.

Can our own staff build ERPNext web forms without a developer?

Staff with ERPNext administration experience can build simple web forms through the desk interface, provided they understand DocType permissions and can test as a non-administrator. Forms that need validation logic, custom server behaviour or changes to how records are linked usually need a developer, and server scripts are disabled by default from version 15, so they must be enabled by an administrator first. Shared hosted benches on Frappe Cloud do not allow server scripts. Decide early which forms are simple enough for internal staff to maintain and which need engineering support.

Do ERPNext web forms need changes when we move to a new ERPNext version?

Web forms are configuration held in the database, so they must be checked after every major upgrade rather than assumed to carry over unchanged. Test each form as a guest and as a portal user, confirm that fields still map to the same DocTypes, and review any server script or custom field logic. Frappe lists supported versions on its support versions page, and version 14 reached end of life on January 31, 2026, so plan upgrades before a version leaves support. Include form regression tests in the upgrade plan.

Should customer and supplier forms be open to guests or limited to logged-in users?

Guest forms suit public intake such as applicant or enquiry forms where the visitor has no account. Login forms suit customers and suppliers who must view or update their own records, because access then depends on the user's permissions and linked party. For sensitive data such as bank details or tax identifiers, login is usually the safer choice. Confirm with your security team which fields are personal data, and decide how you will verify identity before a supplier can change payment details.

What checks should an engineer run on exposed ERPNext DocTypes and list views?

Start by listing every DocType a form writes to or a portal user can read, then test each one with a user who has only the portal role. Check that list views show only records linked to that user, that no hidden fields leak through the API, and that guest users cannot reach list endpoints. Review user permissions and any field-level restrictions, and confirm that the access rules hold after an upgrade. Record the test results so the internal team can repeat them.

How DeployOpen scopes and delivers ERPNext web forms

DeployOpen plans, builds, documents and supports ERPNext web forms for customers, suppliers and applicants inside your own infrastructure. We start from the written scope, decide which DocTypes and permissions an outside user may reach, and hand over a tested, documented setup your team can run.

How we scope

Map each external audience to a login or guest form and record the reason for the choice.
List every DocType exposed, the fields each user may read or edit, and the data they must never see.
Agree in writing which forms, list views, notifications and test cases are in scope before work starts.
Confirm the ERPNext version, hosting model and identity source so the build matches your environment.

How we build

Configure web forms and portal list views with permission checks tied to the customer, supplier or applicant record.
Add validation, linked-master lookups and file attachments only where the business process needs them.
Keep customizations in a custom app or exported fixtures so they can be versioned and deployed the same way each time.
Test guest and logged-in paths with users in each role, including attempts to reach records belonging to other parties.

How we hand over

Provide written documentation of each form, its target DocType, its permissions and its data flow into ERPNext.
Walk your administrators through how to add fields, change forms and review submissions without breaking access rules.
Deliver the test cases and results so your team can repeat permission checks after future upgrades.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the initial handover.
Review web form permissions again when you add a new DocType, company, role or login method.
Confirm the scope of each retainer in writing so the support boundary is clear before it starts.

ERPNext web forms for customers, suppliers and applicants