How to Protect Proprietary Formulations Inside an Open-Source ERP

Every chemical manufacturer we meet asks the same question within the first thirty minutes of a demo. If ERPNext is open source, can anyone see my formula? It is a fair question, and the answer is worth understanding properly, because the ability to protect formulation data in ERPNext does not depend on the source code being hidden. It depends on how you configure permissions, how you structure your bills of materials, and where the system is hosted. This article walks through each of those decisions the way we set them up on live sites, so you can judge for yourself whether an open-source platform is safe for your recipes.

Open source means the code is public, not your data

The confusion is understandable. Two different things get bundled under the word open.

Open source means the application code of ERPNext and the Frappe Framework is published under a GPLv3 licence. Anyone can read it, audit it, and modify it.

Your data is a separate matter entirely. It lives in your database, on your server, behind your login. Publishing the code does not publish the contents of the database any more than publishing the blueprints of a safe publishes what is inside it.

Security professionals have argued this point for over a century. A lock that only works because nobody knows how it is built is a weak lock. Proprietary ERP vendors keep their code closed for commercial reasons, not because closed code is inherently safer. What actually keeps your formula private is access control, hosting discipline, and an audit trail. Those are all things you control directly in ERPNext, and in most cases control more tightly than you could in a hosted proprietary system where the vendor's staff also has database access.

The real risk to a formulation is almost never an outsider reading GitHub. It is a production supervisor who quits on Friday with a spreadsheet export of every BOM in the system.

Start with a threat model, not a feature list

Before touching a single permission setting, decide what you are defending against. In chemical manufacturing industry deployments, the realistic exposure points are these:

The departing employee: Someone with legitimate day-to-day access who copies data before leaving. This is the most common and the most damaging.
The over-privileged user: An accounts person who was given the Manufacturing Manager role during go-live because it was quicker than configuring properly, and who never had it removed.
The silent export: A user with report access who downloads BOMs to Excel. No alarm goes off, and the file leaves the building.
The print format leak: A Work Order or Job Card print that shows the complete ingredient list, handed to a contract packer or a job-work vendor.
The integration: An API key issued for a third-party dashboard that quietly has read access to everything.
The backup: A full site backup sitting unencrypted on a shared drive, containing every table in the database.

Notice that five of those six have nothing to do with whether the software is open source. They are configuration and process problems, which is exactly why the licensing question is the wrong one to lead with.

Layer 1: Role-based permissions on the documents that hold your formula

In ERPNext, the recipe lives in the BOM (Bill of Materials), supported by Item, Item Group, Quality Inspection Template, and, in most chemical implementations, a custom formulation or specification doctype.

Permissions are managed through the Role Permissions Manager, where you grant rights per role, per document type. For each combination you decide whether the role can read, write, create, delete, submit, cancel, amend, print, email, report, export and share.

A workable starting model for a chemical plant looks like this:

R&D Manager: full rights on BOM and formulation records, including create and amend.
Production Manager: read on BOM, full rights on Work Order and Job Card. Cannot amend a formula, only execute it.
Shop floor operator: rights on Job Card only. No BOM access at all.
QC Executive: rights on Quality Inspection and specifications, read-only on the BOM header.
Purchase and Stores: rights on Item and Stock entries, no BOM access.
Accounts: costing reports only, with BOM detail suppressed.

The principle is dull but effective. Nobody gets a role because it is convenient during implementation. Every role is granted because the job cannot be done without it.

One more point that gets missed: the System Manager role bypasses most restrictions, and so does the Administrator account. On a properly run site, System Manager belongs to one or two people, and Administrator is used only for maintenance and secured with two-factor authentication.

Layer 2: Field-level protection using permission levels

This is the control that does the real work, and it is the one most implementation partners skip.

In Frappe, every field on a form has a permission level (permlevel), a number from 0 upward. Level 0 is the default and covers ordinary fields. If you raise a field to level 1, only roles explicitly granted level 1 access can see or edit it.

Applied to a BOM, that gives you something genuinely useful. You can allow a production planner to open the BOM, see the product, the batch size, the operations and the routing, while the quantity and rate columns of the ingredient table stay hidden. They know a batch of Resin X-40 takes eight raw materials and runs through three operations. They do not know that it takes 42.6 kg of one of them.

Typical field-level configuration in a chemical implementation:

BOM item quantity, rate and amount raised to permlevel 1, visible only to R&D Manager and Costing Head.
Custom fields holding reaction parameters, catalyst ratios or addition sequence raised to permlevel 2, visible only to R&D.
Supplier and landed cost fields on the Item raised to their own level so that formulation staff cannot see commercial terms and purchase staff cannot see formulation detail.

The result is one shared system where every department works on the same live data, and no single operational role can reconstruct the recipe. Compare that with the usual alternative, a password-protected Excel file on the R&D head's laptop that gets emailed around whenever he is on leave.

Layer 3: Structure the BOM so the sensitive part is not on the shop floor

Permissions control who can read a record. Structure controls what the record reveals in the first place. Two techniques work well in ERPNext for chemical industry setups.

Use pre-mix sub-assemblies. Instead of one flat BOM listing every ingredient, define an intermediate item, for example PREMIX-X40-A, produced under its own Work Order in a restricted work centre. The finished-goods BOM then shows the pre-mix as a single line. Operators on the main line see a pre-mix going in. Only the small team producing the pre-mix sees what is inside it, and their access is restricted to that BOM alone. This mirrors how many specialty chemical firms already work physically, with a locked dosing room, so the ERP structure matches the plant.

Mask item nomenclature. Store raw materials under internal codes rather than chemical names, with the descriptive name held in a permlevel-restricted field. A stores clerk issues RM-A17 from the flammable store. He does not need the CAS number or the trade name to do that correctly, and the coded picking list is useless to a competitor.

Neither technique is exotic. Both are ordinary ERPNext configuration, and together they mean that even a full data export from an operational login yields codes and pre-mix references rather than a usable recipe.

Layer 4: Close the export, print, share and API doors

Access control fails quietly when data can walk out through a side channel. Four settings deserve specific attention.

Export. Report-level export is a separate permission from read. Remove it for every operational role. If a manager genuinely needs data in Excel, give them a defined report with the sensitive columns already excluded, rather than raw list-view export.

Print. Build restricted print formats. A Job Card print for the shop floor should show operation instructions, safety notes and quantities of what that station handles, not the full ingredient breakdown. A job-work challan going to a toll manufacturer should carry item codes and quantities without composition.

Share. Frappe lets users share individual documents with other users. Withdraw the share permission from roles that have no business redistributing records, and review the share log periodically.

API and integrations. Every API key inherits the roles of the user it belongs to. Create dedicated integration users with the narrowest possible role set, never a System Manager key, and rotate keys when a vendor engagement ends. The same applies to webhooks and to any BI connector reading directly from the database.

Also worth adding to your offboarding checklist: disable the user account rather than deleting it, so the audit history stays intact, and revoke API keys the same day.

Layer 5: Hosting decides who else can reach the database

An open-source licence gives you an option that proprietary SaaS does not. You choose where the system runs.

Self-hosted on your own infrastructure or private cloud. The database sits on hardware you control. No vendor employee has standing access. For firms with genuinely high-value formulations, this settles the question.
Single-tenant managed hosting. Your instance runs on its own server, managed by your implementation partner under a signed agreement. Common, practical, and adequate for most SMEs.
Shared multi-tenant hosting. Cheapest, and the least appropriate for confidential formulation data.

Whichever you pick, the hygiene is the same: TLS on all traffic, two-factor authentication enabled for privileged roles, IP restriction on the User record for administrative accounts where practical, encrypted and access-controlled backups, and a documented list of who holds server credentials. Backups are the softest target in most installations. A perfectly permissioned ERP is worth little if last night's SQL dump is sitting in an open folder.

Layer 6: Prove who looked at what

Confidentiality is not only about prevention. When something does leak, you need to know where it went, and if you supply regulated customers you may need to demonstrate control of your records anyway.

ERPNext keeps several trails without any customisation:

Version records capture every change to a tracked document, including which field changed, from what value to what value, by whom, and when. Enable change tracking on BOM and on your formulation doctype.
Access Log records printing, downloading and emailing of documents.
Activity Log records logins and session activity.
Error and Route logs help reconstruct unusual access patterns.

Set up notifications on the events that matter, for example an alert to the R&D head whenever a BOM is amended or a new user is granted a formulation role. Reviewing these logs once a quarter takes an hour and tends to surface exactly the permission creep described earlier.

A rollout sequence that works

If you are implementing or cleaning up an existing site, do it in this order:

List every document type that touches formulation data, including custom fields and reports.
Draft the role matrix on paper with department heads before configuring anything.
Configure roles, then permission levels, then user permissions for company or item group restrictions.
Restructure BOMs into pre-mixes and apply coded nomenclature where it is warranted.
Strip export, print and share rights, then build the replacement reports and print formats people actually need.
Audit existing users and API keys. Expect to find surprises.
Enable change tracking and notifications.
Test by logging in as each role and trying to get the formula out. If you can, so can they.

That last step is the one that separates a real configuration from a documented intention.

Mistakes we see most often

Granting System Manager during go-live temporarily and never revoking it.
Relying on hiding a field in the form layout, which does nothing, since the data is still available through reports and the API. Only permission levels actually restrict it.
Leaving export enabled for every role because someone once needed a spreadsheet.
Building one enormous flat BOM and then trying to protect it with permissions alone.
Treating the formulation as protected while the same values sit in an unrestricted custom report, a dashboard, or a print format nobody reviewed.
Skipping two-factor authentication on privileged accounts.

Frequently asked questions

Is ERPNext safe for confidential chemical formulations?

Yes, provided it is configured for it. The open-source licence exposes the application code, not your database. Formulation confidentiality in ERPNext comes from role-based permissions, field-level permission levels, restricted print and export rights, controlled hosting and change tracking. A well-configured ERPNext instance typically gives a manufacturer tighter control over formulation access than the spreadsheets and shared drives it replaces.

Can I hide BOM ingredient quantities from production staff in ERPNext?

Yes. Raise the quantity, rate and amount fields of the BOM item table to a higher permission level and grant that level only to R&D and costing roles. Production users can then open the BOM, view the product, batch size and routing, and execute Work Orders without seeing the proportions.

Does open-source ERP mean my competitors can access my recipes?

No. Public source code does not expose private data. A competitor would need valid credentials on your server, and that is a question of your access control and hosting, which is identical to the risk profile of any proprietary ERP.

How does ERPNext track who viewed or changed a formulation?

Enable change tracking on the BOM and formulation doctypes. Frappe then creates a Version record for each modification showing the field changed, the old and new values, the user and the timestamp. The Access Log separately records printing, downloading and emailing of documents, and the Activity Log records logins.

What is the difference between role permissions and permission levels in ERPNext?

Role permissions control access to an entire document type, for example whether a role can read or edit a BOM at all. Permission levels control access to individual fields within that document. You need both. Role permissions decide who opens the record, permission levels decide how much of it they see.

How do I stop employees from exporting formulation data to Excel?

Remove the export permission from operational roles in the Role Permissions Manager, since it is granted separately from read access. Replace it with purpose-built reports that exclude sensitive columns, and review the Access Log for download activity.

Should I self-host ERPNext to protect my formulations?

Self-hosting or single-tenant private cloud is the stronger option when formulations are a core commercial asset, because no external party holds standing database access. Managed single-tenant hosting under a confidentiality agreement is adequate for most small and mid-sized manufacturers. Shared multi-tenant hosting is the weakest choice for this kind of data.

Can a job-work vendor be given ERPNext access without seeing the formula?

Yes. Give the vendor a restricted portal or supplier user with access limited to Subcontracting Orders and the materials supplied to them, and use print formats that show item codes and quantities without composition. Combined with pre-mix sub-assemblies, the vendor receives what they need to process the job and nothing more.

Where Sigzen fits

Sigzen Technologies is a certified ERPNext and Frappe implementation partner based in Ahmedabad, working with chemical manufacturers across India. SigzenCHEM, our chemical industry solution built on ERPNext, ships with a formulation access model of the kind described above, along with batch production, QC and COA workflows, hazmat inventory rules and compliance tracking.

If you want your existing ERPNext site audited for formulation exposure, or you are evaluating ERPNext and want the confidentiality question answered against your actual process, our team will walk you through it on a live system.

How to Protect Proprietary Formulations Inside an Open-Source ERP