← back to docs
[guides] modules extensibility bridges extensions composition

Module Extensibility

Extend and compose modules without forking them. Bridge modules add fields and logic across other modules; extension columns layer onto entities you don't own; dependencies keep it all upgrade-safe.

published

Module Extensibility

dForge modules are designed to compose, not to be forked. You can add fields, views, actions, and cross-module logic on top of modules you didn’t write — and still take their upstream updates. Three mechanisms make that work: dependencies, extension columns, and bridge modules.

Dependencies

Every module’s manifest.json declares the other modules it needs. admin is always required; the rest you opt into. When a module depends on another, it can reference that module’s entities, roles, and settings — so a Finance module can build on the shared customer identity in parties instead of redefining it.

Dependencies are versioned, so an install resolves the whole tree and refuses combinations that don’t satisfy each module’s constraints.

Extension columns

You can add columns to an entity that another module owns — without modifying that module. The extra columns live in a separate 1:1 table keyed to the base record; the query builder JOINs them in automatically, so they appear as if they were native fields.

Because your additions never touch the base module’s tables, the base module can ship a new version and your extension keeps working. Example: CRM layers industry, credit_limit, and account_manager onto the shared parties record without owning it.

Bridge modules

A bridge module connects two modules and adds the logic that only makes sense when both are installed. It depends on both, extends entities from each, and contributes new actions or lookups.

Real examples from the catalog:

  • crm-fin — quote-to-invoice conversion, invoice lookups on quotes, credit-limit checks across CRM and Finance.
  • wms-fin — PO-to-bill conversion and vendor lookups across Warehouse and Finance.
  • crm-pricing / wms-pricing — a “Refresh prices” action that pulls from the Pricing module.

Install the bridge only when you run both sides; uninstall it and the base modules are untouched.

Why this beats forking

Forking a module to change it means you inherit none of its future fixes and features. Extending it means:

  • Upgrade-safe — update either base module and your extension/bridge keeps working.
  • Composable — each tenant assembles its own stack; one runs CRM + Finance + a bridge, another runs Warehouse + Pricing.
  • Reviewable — your additions are their own metadata you can read, diff, and version, separate from the modules you build on.

Three tiers, one runtime

System modules (maintained by dForge), community modules, and your own custom modules all run on the same engine with the same extension model. A custom module extends a system module exactly the way one system module extends another.

← previous Dashboards next → Views Guide
/ was this helpful?

Stuck on something?
Tell us.

We read every message and update the docs based on what readers ask. The fastest way to improve the docs is to write to us.

Contact support → All docs