Every manufacturer that buys an ERP asks for changes within weeks: a field the plant has always recorded, a column on a report, an extra approval, a document the industry needs. How those changes are made decides the next five years. Done well, the system fits the plant and still upgrades cleanly. Done badly, every change is custom code, every upgrade breaks something, and the plant ends up frozen on an old version it is afraid to touch. This guide explains how to sort change requests, which ones need no code at all, and how to add new features without losing existing data – with a worked quarter of requests.
Four kinds of change
- Screen configuration – add, hide or rename a field, a grid column or a lookup. This should be done with a form designer, by a trained key user, without code.
- Reports – a new column, filter or grouping. Often a configuration; sometimes a new report built on the same data.
- Rights and approvals – who can see, save, delete or approve. Pure configuration; see approval workflows and user rights.
- New documents or processes – something the system does not do yet. This is real development and needs a design, testing and a controlled release.
Worked example: one quarter of change requests
Tejaxo Manufacturing (sample data) logged 12 change requests in its first quarter on a new ERP:
| Change | Count | Done by | Upgrade risk |
|---|---|---|---|
| Add or hide a field, grid or lookup | 6 | Key user | None |
| New report or column | 3 | Key user / partner | Low |
| Approval or rights change | 2 | Admin | None |
| New document or process | 1 | Partner | Managed |
8 of 12 requests – 67% – needed no code: screen configuration and rights changes made by the key user and the administrator in a day. Three were reports. Only one was a genuinely new process, handled as a small project. Before the plant learned to sort requests this way, every one of them went to the vendor as a “customisation”, waited in a queue and added risk to the next upgrade, while users waited and kept using spreadsheets.
Why custom code breaks upgrades
When the standard screens and tables are edited directly, an upgrade either overwrites the change or fails because the structure it expects has changed. Plants then delay upgrades, miss fixes and statutory updates, and pay for the same change again later. The safer pattern is to keep the core standard, make screen and report changes through configuration that survives upgrades, and add genuinely new features as additions rather than edits.
Adding features without losing data
New features almost always need new fields, menus or screens. The safe way to add them is an update that adds only what is missing – new columns, menus and forms – and leaves existing tables and records as they are. Existing data keeps working, existing reports keep running, and the new feature appears alongside. Before any update: take a backup, apply it to a test copy, run the key transactions and reports, then apply it to the live system.
A simple change-control routine
- One request log – every request with who asked, why, and the business result expected.
- Classify – configuration, report, rights or new process.
- Configuration and rights are done by the trained key user or admin, recorded in the log, and checked by the requester.
- Reports and new processes go to the implementation partner with a short written specification and test cases.
- Release new processes on a test copy first, then live, with users told what changed.
- Review the log quarterly – repeated requests in the same area often point to a training gap, not a missing feature.
The key user
Configuration only works if someone inside the plant owns it. A key user – often from accounts, stores or planning – is trained on the form designer, report filters and rights, and becomes the first stop for every request. Because they know both the business and the system, they can tell in minutes whether a request is a configuration, a training point or a real development need. One key user per area is usually enough; what matters is that they have time set aside for it and a clear rule about what they may change on their own and what needs approval. Plants that skip this role end up sending every small change to the vendor, which is slow for them and expensive for everyone.
Saying no – or not yet
Not every request should be built. “Can the screen look like our old register?” may simply copy an old inefficiency into a new system. Ask what decision or control the change supports. If the answer is weak, record the request and revisit it after a few months of use; many disappear once people are used to the new flow, and the ones that remain are usually the changes that really matter.
Working with the ERP you already have
Plants on SAP, Microsoft Dynamics or Oracle face the same choice at a larger scale: changing the core is slow and expensive, so the better path is to build portals, shop-floor apps and dashboards around the ERP and connect them through APIs or scheduled sync, without touching its core – see extending SAP and Dynamics.
Support after go-live
Most change requests arrive after go-live, when users meet real situations. The team that implemented the system is best placed to handle them, because it knows why each setting was chosen. Agree in advance how requests are logged, how quickly configuration changes are made and how new features are scheduled, so the system keeps improving instead of drifting.
How Tejaxo handles it
Tejaxo ERP has a no-code form designer to add or hide fields, grids and lookups on screens, menu-level rights and approval workflows, and reports that export to Excel and drill down to the records. New features are added through an “Update Database” action that adds only missing columns, menus and forms, so existing data keeps working. Post-go-live support, monitoring and upgrades are provided by the same team under AMC, with NDA and documentation – see the ERP implementation process and ERP data migration.
Common mistakes
- Treating every request as development, so simple field changes wait weeks.
- Editing the core directly, which makes the next upgrade a project.
- No test copy, so changes are tried for the first time on live data.
- No request log, so nobody knows why a field exists two years later.
Next step
See the form designer, rights and the update process on your own screens in a free demo.
Frequently asked questions
Can an ERP be customised without code?
Many changes can: adding or hiding fields, grids and lookups, changing rights and approvals, and adjusting reports. Tejaxo ERP has a no-code form designer for screen changes.
Why do customisations break ERP upgrades?
Because direct edits to standard screens and tables are either overwritten by the upgrade or conflict with the new structure. Configuration and additive changes survive upgrades.
How should new ERP features be added safely?
With an update that adds only missing columns, menus and forms and leaves existing data untouched, applied first to a test copy after a backup.
Who should handle ERP change requests?
Trained key users and administrators for configuration and rights; the implementation partner for new reports and processes, with a written specification and testing.
How do we decide which changes to build?
Ask what decision or control the change supports. Weak cases are logged and revisited after a few months; many disappear once users are used to the new flow.
Does Tejaxo provide support after go-live?
Yes. Post-go-live support, monitoring and upgrades are provided by the same team under AMC, with NDA and documentation.
