Core Concepts

The Core Idea

dForge turns business definitions into running applications. You describe what your business needs — entities, fields, views, security rules — and the platform handles how it gets built, deployed, and secured.

This is the metadata-driven approach. There is no code generation step that produces files you have to maintain. The platform reads metadata at runtime and behaves accordingly.

Tenants

A tenant is an isolated workspace with its own database. Each organization that uses dForge is a tenant.

• One PostgreSQL database per tenant
• One database user per tenant
• Modules installed per tenant — different organizations can use different combinations
• No shared tables, no shared metadata, no risk of cross-tenant data leakage

A separate auth database stores user accounts and tracks which tenants each user can access.

Modules

A module is a self-contained package of business functionality:

• Entities (database tables)
• Views (how data is displayed)
• Menus (navigation structure)
• Roles (security definitions)
• Actions (custom business operations)
• Settings (configurable values)
• Seed data (initial records)

Modules are installed per tenant. Installing a module creates its database tables, registers its metadata, and adds its menus to the user interface.

Modules can depend on other modules and extend each other through bridge modules. A crm-finance bridge adds quote-to-invoice conversion without modifying either the CRM or Finance module.

For a deeper walkthrough of the module concept — anatomy, composition, ecosystem tiers, and how it compares to alternatives — see What is a dForge module?.

Entities

An entity is a business object — a table in the database. Examples: Account, Contact, Invoice, Employee, Stock Movement.

Each entity has:

• Code — the table name (e.g., account)
• Fields — the columns
• Constraints — check rules and unique indexes
• Views — ways to display the entity’s data
• Actions — custom operations available on records

See the Fields Reference for the full list of field types.

Views

A view defines how users see and interact with entity data. Every menu item links to a view. Views combine a data source (which records to show) with a layout (how to display them).

View types: grid, card, kanban, calendar, list, gallery.

See the Views Guide for details.

Folders

A folder is a dynamic filtered view, not a physical container. Records don’t “belong” to a folder — they appear in it when they match the folder’s filter, and the same record can appear in many folders at once.

Folders are the uniform navigation concept in dForge. Top-level folders correspond to installed modules, but everything below — departments, regions, statuses, custom queries — is also a folder. The term “module” is internal; users see folders all the way down.

Each folder defines:

• Filter criteria — which records appear (e.g., status = 'draft')
• Role assignments — who has what permissions inside this folder
• Field overrides — a field can be editable in one folder and read-only in another
• Settings overrides — module settings can be different per folder

Folders are hierarchical. Child folders inherit security and settings from their parent unless explicitly isolated.

Security Model

dForge uses a layered security model:

• Roles define what entities, actions, reports, and folders a user can access. Entity rights use letter codes: S (Select), I (Insert), U (Update), D (Delete), C (Clone). Actions, reports, and folders use E (Execute/Access).
• Folders define what records a user can see (row-level security via filter)
• Views define what fields they can see (column-level security)
• Actions can have their own permission rules (canExecute formulas)

Roles are additive — multiple roles merge their permissions, never revoke. A user with roles granting SU and SIC ends up with SIUC.

Roles can be folder-scoped — a user can be hr.manager globally but only hr.viewer inside the “Executives” folder.

See the Administration Guide for the full security model.

Formulas

Formulas are expressions used throughout the platform:

• Calculated columns — compute values from other fields
• Validation rules — enforce business logic
• Action conditions — control when actions are available
• Row-level security — restrict which records are visible
• Default values — set initial values on new records

Formulas can reference other fields with [field_name], navigate through references with [field].[other_field], and use built-in functions like IF, TODAY, NOW.

See the Formulas Reference for the full syntax.

Actions

Actions are custom server-side operations beyond basic CRUD. Examples:

• Convert a lead into an account, contact, and opportunity
• Generate an invoice from a quote
• Transfer stock between warehouses

Actions are defined in a simple DSL with three blocks: params: (what the user provides), canExecute: (when the action is available), and execute: (what happens). The DSL has access to the current record’s fields, parameters, and built-in functions for queries, inserts, and notifications.

See the Actions Guide for details.

Localization

dForge is built for multi-language operations from the ground up.

Translatable Metadata

Every metadata definition supports translations:

• Entity names and descriptions
• Field labels and tooltips
• Menu items and section names
• Action names and parameter labels
• Module names and settings

Translations are stored separately from the structural metadata, so you can add new languages without modifying entity definitions.

Per-Tenant Translation Overrides

Tenants can override default translations. A vertical-specific deployment can rename “Account” to “Patient” or “Customer” without forking the module.

Locale-Aware Display

The user interface respects the user’s locale for:

• Date and time formatting
• Number and currency formatting
• Translated labels and messages

Modules ship with default translations and can include locale-specific seed data.

API

dForge exposes RPC-style endpoints for all operations:

POST /api/exec      # authenticated calls
POST /api/invoke    # session-less calls (login, password reset)

/api/exec takes a method name, parameters, and a folder context (security is folder-scoped, not global). The method registry includes:

• data.get — query records
• data.set — insert, update, or delete records
• action.execute — run an action
• action.getEntityActions — list available actions for an entity
• report.run — execute a report
• settings.list, settings.set — manage module settings

Multiple method calls can be batched into a single request with hierarchical sub-requests and position-based responses. The frontend SDK auto-batches calls made in the same microtask. Files are served via GET /api/file/{folder}/{entity}/{field}/{key}.

Note: A traditional REST API is on the roadmap for external integrations. For now, the RPC endpoint and frontend SDK are the supported integration points.

Audit & History

Every data modification can be tracked:

• Who made the change
• What changed (old value, new value)
• When it happened
• Which action or API call caused it

Modules can opt into full audit history for sensitive entities (e.g., Finance module enables it for all financial transactions).

Next Steps

• User Guide — work with data as an end user
• Administration — manage users, roles, and folders
• Studio Guide — build modules visually
• Fields Reference — all field types and their options
• Views Guide — grid, card, kanban, calendar, list layouts
• Formulas Reference — expression syntax and functions
• Actions Guide — custom DSL operations