ERP Strategy • Process Improvement • Custom Development
Customise or Change the Process? Our Framework for Making the Decision
When an ERP system does not behave exactly as a team expects, the first request is often: “Can we customise it?” Sometimes the answer is yes. But before writing code or adding another approval, we need to understand why the process works that way in the first place. Is the requirement essential? Does the standard system already support it? Could a configuration change solve the problem? Or is the business trying to preserve a process that no longer adds value?
1. The real question is not whether we can customise
Consider an illustrative UAE distribution company, Gulfline Trading. Its sales team wants every quotation to pass through three approvals before it can be sent to a customer.
The request sounds reasonable at first. The team wants better control over discounts and commercial commitments. But when we examine the process, we discover that:
- Most quotations are standard and fall within approved price limits.
- Sales managers already have authority to approve routine discounts.
- Only exceptional discounts require senior management review.
- The current three-step process delays even straightforward quotations.
We could build a custom approval sequence. But would that solve the actual problem? It might simply make an inefficient process happen inside the ERP.
The better question is: What business risk are we trying to control, and what is the simplest reliable way to control it?
Our principle: understand the business requirement first. Then choose the lightest solution that meets it without creating unnecessary long-term complexity.
2. There are four possible routes—not just two
The decision is often described as “customise or do not customise”. In practice, we consider four routes.
Route 1: Change the process
Use this route when the existing process includes unnecessary steps, repeated data entry, outdated approvals or workarounds that no longer serve a clear purpose.
Examples include:
- Removing duplicate data entry between departments.
- Replacing routine manual approvals with agreed authority limits.
- Changing the order of activities so information is captured once.
- Using standard system reports instead of maintaining several spreadsheets.
Process change is often the simplest option, but it still needs stakeholder agreement, clear procedures and training.
Route 2: Use the standard ERP functionality
Sometimes the required capability already exists. The team may not know where to find it, how to configure it or how it fits into the wider workflow.
Before proposing development, we check the standard features, available reports, permissions, workflows and supported transaction options in the relevant ERP version.
Route 3: Configure the ERP
Configuration adapts supported system options to the business without necessarily building a separate application feature.
Depending on the ERP and requirement, this may involve:
- Adding custom fields or adjusting form layouts.
- Setting up approval workflows and role permissions.
- Configuring naming rules, notifications and defaults.
- Creating reports and print formats.
Configuration is not maintenance-free. It should still be documented, tested and reviewed when the system is upgraded.
Route 4: Develop a custom extension
Custom development becomes appropriate when the requirement is genuinely important and cannot be met reliably through process change, standard functionality or supported configuration.
Examples may include a specialist calculation, a complex integration, a unique operational workflow or a mandatory business rule that the standard system does not support.
Where possible, the extension should be designed as a modular component rather than an untracked change to the ERP’s core code.
3. Our practical decision matrix
The following matrix helps compare the options before a decision is made. The ratings are relative planning guidance, not fixed guarantees. Actual effort depends on the ERP version, complexity, hosting model, integrations and quality of the implementation.
| Decision factor | Change process | Use standard ERP | Configure ERP | Custom development |
|---|---|---|---|---|
| Best suited for | Unnecessary or outdated steps | Existing supported capability | Supported options need adjustment | Essential requirement not otherwise met |
| Initial effort | Low to medium | Low | Low to medium | Medium to high |
| Business change required | Potentially high | May require user adaptation | Usually limited | Usually limited, but process alignment still matters |
| Ongoing maintenance | Procedure and training reviews | Standard product support | Configuration review and testing | Code ownership, support and regression testing |
| Upgrade considerations | Usually low technical impact | Follow product upgrade path | Validate configuration after upgrades | Test compatibility and update extension where needed |
| Documentation needed | Updated process instructions | Feature and user guidance | Configuration and approval records | Functional and technical design, code and test records |
| Best owner | Process owner | Functional ERP owner | Business and ERP team | Business owner and development team |
Questions to ask before choosing a route
- Is the requirement essential? Is it driven by compliance, contractual obligations, customer expectations, risk or a genuine operational need?
- Does the standard ERP already support it? Check the relevant version and configuration before assuming development is required.
- Can the process be simplified? Is the requested behaviour compensating for an unnecessary step or an unclear responsibility?
- Can supported configuration solve it? Could a workflow, permission, field, report or existing setting meet the need?
- What happens if we do nothing? Identify the actual operational, financial or compliance consequence.
- Who will maintain the solution? A custom feature needs a named owner, technical support and a plan for future changes.
A useful decision rule: if a requirement is not essential, simplify or remove it. If the standard system supports it, use that capability. If supported configuration can meet it, configure it. Develop only when the remaining gap justifies the ongoing responsibility.
4. The maintenance question must be asked before development
A custom feature may take a few days to build, but it can remain part of the business system for years. The initial development estimate is only one part of its cost.
Before approving a customisation, we consider five ongoing responsibilities.
A. Who owns it?
Every custom feature needs a business owner who can explain why it exists, what outcome it supports and whether it is still required.
It also needs a technical owner who understands the implementation, dependencies and support requirements. If the original developer leaves, another person should be able to maintain it using the available documentation and source code.
B. What needs to be tested?
A custom approval rule, calculation or integration can affect more than the screen where it appears. It may influence document submission, accounting entries, stock updates, permissions or downstream reports.
Testing should cover the intended scenario, normal use, exceptions, permissions and relevant connected workflows. For important business logic, include regression tests so a future change does not quietly break an existing process.
C. What happens during an upgrade?
ERP upgrades can change standard forms, APIs, data structures, business logic and dependencies. A custom feature that worked in one version may need adjustment in another.
Before upgrading, identify the custom components, check their compatibility, test them in a non-production environment and resolve failures before the production release.
D. Is the feature documented?
Documentation should explain:
- The business requirement and approved process.
- Where the custom feature is implemented.
- Which standard documents, fields or APIs it depends on.
- Who owns the business rule and technical support.
- How the feature is tested and deployed.
- What needs to be checked during an ERP upgrade.
E. Is the cost still justified?
A custom feature should be reviewed periodically. If the ERP introduces the same capability as standard functionality, or the business process changes, the old extension may no longer be necessary.
Keeping a feature simply because it was expensive to build is not a good reason to maintain it indefinitely.
5. Compare the maintenance and upgrade impact
This table gives a practical starting point for estimating the ongoing responsibility associated with each route.
| Area | Process change | Configuration | Custom extension |
|---|---|---|---|
| Maintenance effort | Review procedures and retrain when needed | Maintain configuration records and validate behaviour | Maintain code, dependencies and deployment process |
| Upgrade testing | Check whether the new system still supports the process | Retest affected forms, workflows, permissions and reports | Run compatibility, integration and regression tests |
| Documentation | Process maps and work instructions | Settings, roles and workflow documentation | Technical design, source code, dependencies and test cases |
| Change ownership | Department or process owner | Business owner and ERP administrator | Business owner, technical owner and development team |
| Risk if owner leaves | Knowledge may be lost | Configuration knowledge may be lost | Business logic and code knowledge may be lost |
These are relative considerations, not a claim that every configuration is upgrade-safe or every custom extension is upgrade-fragile. Design quality, version compatibility, test coverage and deployment discipline make a significant difference.
6. A practical example: should we customise the sales approval process?
Let’s return to Gulfline Trading. The original request is to introduce three approval stages for every sales quotation.
During process discovery, the team identifies three types of quotation:
- Standard quotations: use approved price lists and normal commercial terms.
- Discounted quotations: include discounts within an agreed manager approval limit.
- Exceptional quotations: involve unusually high discounts, special payment terms or non-standard commercial commitments.
Instead of building a three-stage approval for every quotation, the company agrees to simplify the routine route and apply additional control only when a quotation crosses defined thresholds.
| Scenario | Preferred approach | Reason |
|---|---|---|
| Standard quotation within approved terms | Use standard ERP process | No extra approval adds value |
| Discount within manager authority | Configure approval limits or workflow | Control is applied where needed |
| Exceptional commercial terms | Escalation workflow or justified extension | Higher-risk cases receive additional review |
| Duplicate manual quotation register | Change the process | Remove unnecessary parallel tracking |
The outcome is not simply a shorter workflow. It is a more proportionate control: routine work moves faster, while exceptions still receive attention.
If a required approval rule cannot be represented reliably using the system’s supported workflow and configuration options, the team can then assess a custom extension. That decision is based on a defined gap, not an assumption that every request needs code.
7. Our framework for making the decision
At Craft Interactive, the decision should follow a clear sequence. The aim is to avoid developing a solution before the requirement and process are properly understood.
Step 1: Observe the current process
Speak with the people doing the work. Understand the actual steps, handovers, exceptions, approvals and spreadsheets involved—not just the process described in a meeting.
Step 2: Identify the real business need
Separate the requested feature from the problem it is supposed to solve. Is the objective faster processing, better control, less manual work, improved reporting or compliance?
Step 3: Check the standard ERP capability
Review the relevant version, standard workflows, settings, reports and supported extension points. Do not assume that a feature is missing simply because users have not found it.
Step 4: Evaluate process change and configuration
Look for a simpler way to achieve the outcome. If a supported configuration meets the requirement, compare its effort and limitations with a custom build.
Step 5: Estimate the full lifecycle cost
Include initial development, testing, documentation, support, future changes, upgrade compatibility and the cost of finding someone who can maintain the feature.
Step 6: Assign ownership and approve
Confirm the business owner, technical owner, expected outcome, test plan and future maintenance responsibility. Record why the selected approach was chosen.
Step 7: Review after implementation
Check whether the solution actually improved the process. Review custom features after major upgrades and when business requirements change. Remove extensions that are no longer needed.
8. How this applies to ERPNext and the Frappe Framework
ERPNext and the Frappe Framework provide several ways to adapt the system. Choosing the right mechanism is part of the decision—not an afterthought.
Customize Form and supported configuration
Customize Form can be used to add Custom Fields and adjust supported DocType properties. Other configuration options include workflows, roles and permissions, reports and print formats.
These options can address many business requirements without replacing standard application code. See the Frappe documentation on Customizing DocTypes and ERPNext Customisation.
Client Scripts and Server Scripts
Client Scripts can add browser-side form behaviour, such as contextual actions, field interactions and form validation. They should not be treated as the only enforcement point for critical business rules: browser-side validation does not automatically cover API or other server-side operations.
Server Scripts can run server-side logic for supported events or API methods, subject to the deployment environment and security settings. For example, Server Scripts are disabled by default from Frappe version 15 unless enabled by the administrator.
Read the ERPNext Client Scripts documentation, the Frappe Client Script guide and the Server Script documentation.
Custom apps and hooks
For more substantial or reusable functionality, a custom Frappe app may be the better architecture. Apps can use hooks to extend standard events and behaviour. The right design depends on the requirement and the relevant framework version.
Where possible, extend standard behaviour rather than replacing it wholesale. Frappe’s documentation describes hooks and extension approaches, including the considerations involved when multiple apps interact with the same functionality.
See Frappe Hooks and Frappe Apps.
Plan for upgrades from the beginning
Frappe’s migration process can apply application patches and synchronise database schema, fixtures and other application components. That does not mean every custom feature will automatically remain compatible with every future version.
Custom apps and scripts should be reviewed against the target release, tested in a staging environment and included in a controlled upgrade plan. Keep source code under version control and maintain a repeatable deployment and testing process.
See Frappe Migrations and bench migrate.
Keep the core clean.
Use standard functionality where it fits, supported configuration where it is sufficient and modular extensions where the business case justifies them. Avoid direct, undocumented changes to core application code that make future support and upgrades harder.
9. A short approval checklist before custom development
Before approving a custom feature, the project team should be able to answer these questions:
- Is the business requirement clearly documented?
- Is the requirement essential for operations, control or compliance?
- Have standard ERP capabilities been checked for the correct version?
- Have process change and configuration been evaluated?
- Is the expected benefit clear and measurable?
- Are the technical design and dependencies understood?
- Is there a named business owner and technical owner?
- Is there a test and regression plan?
- Has ongoing maintenance and upgrade effort been considered?
- Can the feature be retired if it is no longer required?
If several of these questions remain unanswered, the request is not ready for development approval.
10. The best ERP is not the one with the most custom features
Returning to Gulfline Trading, the company did not need a new three-stage approval system for every quotation. It needed a clearer distinction between routine transactions and exceptional commercial decisions.
Changing the process and configuring the right controls delivered a more practical outcome than building a larger custom workflow from the beginning.
That is the decision we want every ERP project to make carefully. Customisation has a place, but it should solve a real business requirement—not preserve unnecessary complexity.
A well-designed ERP should support the way the business needs to operate today while remaining manageable as the business, technology and software versions evolve.
Frequently asked questions
When should a business customise its ERP?
When a requirement is genuinely important, cannot be met reliably through process change, standard functionality or supported configuration, and the business is prepared to maintain and test the extension over time.
Is changing a business process better than customising an ERP?
Not in every case. Process change is preferable when the existing steps are unnecessary or outdated. Customisation may be justified for essential business rules, specialist operations or integrations that standard functionality cannot support.
Are ERP configurations affected by upgrades?
They can be. Supported configuration is often less complex to maintain than custom code, but it should still be tested after upgrades. The impact depends on the configuration, the ERP version and the changes in the new release.
What is the difference between configuration and custom development?
Configuration uses supported system options such as fields, workflows, permissions and reports. Custom development introduces additional code or application behaviour to meet a requirement that the existing options cannot address adequately.
Can ERPNext be customised without changing its core code?
ERPNext and the Frappe Framework provide mechanisms such as Custom Fields, Customize Form, scripts and custom apps with hooks. The appropriate approach depends on the requirement, framework version and deployment environment.
Who should approve an ERP customisation?
The business owner should approve the requirement and expected outcome. The ERP or technical team should assess the design, effort, security, testing and upgrade implications. Both sides should agree on ongoing ownership before development begins.
Make the right decision before building
At Craft Interactive, we look beyond the feature request to understand the process, business objective and long-term impact. Whether the right answer is process improvement, ERPNext configuration or custom development, the decision should support the business without creating unnecessary complexity.
Let’s review your current workflow and identify the simplest sustainable way to achieve the result.
