1. Why extend with low-code instead of customising the core

Directly changing the ERP core often leads to upgrade pain, vendor lock-in and fragile business logic that nobody wants to touch. Low-code extensions offer an alternative: keep the ERP responsible for authoritative data and core accounting rules, and move experimentation and fast-changing processes into a more flexible layer around it.

Typical goals for low-code extensions:

  • add new workflows without modifying core tables or transactions,
  • experiment with UX and side processes safely,
  • integrate external services without wiring them directly into the ERP engine,
  • let “citizen developers” build tools under clear guardrails.

2. Pattern #1 – Workflow layer on top of ERP

The simplest pattern: keep the ERP as the system of record, but orchestrate approvals and extra steps in a low-code workflow engine. The workflow calls ERP APIs to read or update data and may store only minimal state of its own.

Good candidates:

  • purchase request approvals before a purchase order appears in ERP,
  • exception handling around credit limits, pricing overrides or discounts,
  • manual checks for compliance, quality, or risk.

Declarative platforms like lsFusion fit well here: they allow you to define forms, states and rules declaratively while calling ERP APIs or stored procedures when a workflow step completes.

3. Pattern #2 – Side-car apps for complex processes

Sometimes a process is too domain-specific or fast-changing to live comfortably inside the ERP. In that case, you can build a separate low-code application — a side-car — that uses ERP as a data source and sink.

Typical examples:

  • production dispatching and shop-floor UIs,
  • specialised project or service management tools,
  • configurators for complex products.

The side-car app reads reference data from ERP (customers, products, prices) and writes back only final transactions (orders, time sheets, production results). This keeps the ERP schema clean while allowing the side-car to evolve quickly.

4. Pattern #3 – Event-driven micro-extensions

In an event-driven architecture, the ERP emits events such as order.created, invoice.posted or inventory.below_threshold. Low-code components subscribe to these events and execute small, well-defined actions.

Examples of micro-extensions:

  • sending notifications to chat tools or email,
  • creating follow-up tasks in a ticketing system,
  • pushing aggregated data into analytics or dashboards,
  • triggering automated document generation.

In declarative platforms you typically describe such reactions as rules: 

EVENT orderCreated WHEN Orders.status = 'Approved' DO
            createShipment(Orders);
            notifySales(Orders.customer);

This keeps the extension logic readable and easier to audit than ad-hoc scripts glued on top of the ERP.

5. Pattern #4 – Low-code reporting and “operational BI”

Many ERP users need quick ad-hoc reports with filters, groupings and calculated fields. Instead of building every report in the ERP core, you can expose read-only views and let a low-code reporting layer handle visualisation and slicing.

Benefits:

  • business users can iterate on reports without deployments,
  • read-only access reduces the risk of accidental data changes,
  • aggregation logic can evolve faster than the ERP schema.

6. Guardrails: how not to break the ERP

Low-code power comes with responsibility. A few rules help keep the core safe:

  • Single source of truth. core financial and inventory data live only in ERP.
  • Clear ownership. each workflow knows which system is responsible for which part.
  • Versioning. low-code apps should be versioned and tested just like code.
  • Access control. reuse ERP roles and permissions where possible.
  • Monitoring. log and trace low-code actions that touch ERP data.

7. Where low-code is a bad idea

Some areas still belong strictly to the ERP core or to traditional development:

  • posting logic for accounting and tax,
  • regulatory reports with strict formats,
  • performance-critical batch processes over huge datasets,
  • security-sensitive modules handling secrets or compliance-critical data.

Conclusion

Low-code is not a replacement for ERP — it is a way to extend and protect it at the same time. By using workflow layers, side-car apps, event-driven micro-extensions and low-code reporting, organisations can experiment and iterate quickly while keeping the ERP core stable, upgradeable and clean.