Appearance
Studio concepts and architecture
What is ERP Studio?
ERP Studio is the design environment of the platform. You describe an application (data, screens, forms, logic, workflows, security) as JSON metadata using visual designers; the platform reads that metadata and runs it. Nothing is generated as source you must maintain, and nothing needs a redeploy of the platform when you publish.
What Studio generates vs what you configure
| You configure in Studio | The platform provides from it |
|---|---|
| Entities and fields | database tables, CRUD REST API, lookups, audit trail |
| Pages, forms, blocks | the React web and mobile screens, rendered from JSON at run time |
| Providers, data views, data services | read/write endpoints and queries, permission-filtered |
| Rules, validations, workflows | server-side enforcement, approval tasks, history |
| Roles, permissions, policies | checks on every API, page, field and record |
| Plugins with code | a packaged backend (embedded or its own service container) |
Core concepts (one line each)
| Term | Meaning |
|---|---|
| Tenant | your organization's isolated space: its data, users, themes, installed plugins |
| Environment | a separate tenant or stack used for development, test, staging or production |
| Application | a product area users open (HCM, CRM); contains modules |
| Module | a group of pages inside an application (Leave, Payroll) |
| Plugin | a versioned package of artifacts (and optional code) that installs into a tenant |
| Page / Component / Widget | a routable screen; its parts are blocks (Studio's word for widgets/components) |
| Entity / Field | a record type and its columns |
| API | an endpoint: generated for entities, declared through providers and services, or written in plugin code |
| Workflow / Event / Job / Queue | multi-step processes; things that happened; scheduled work; asynchronous message channels |
| Connector | a saved connection to an outside system |
| Role / Permission | a named set of allowed actions / one allowed action |
| Artifact | any one designed item; a JSON document with a name and version |
Architecture in short
- Metadata-driven: designers edit JSON; the JSON is validated against a schema; the runtime renders and enforces it.
- Draft, published, version: a draft is freely editable; Publish freezes a version (1.0.0, 1.0.1). Users only see published versions; History restores older ones.
- Tenant isolation: every request carries the tenant; storage, queries and indexes are scoped to it.
- Plugin architecture: an installable unit. Embedded plugins run inside the platform; service-mode plugins run in their own container behind the gateway, controlled from Studio (see Backend services).
- Shared vs application-specific services: platform engines (entities, workflows, notifications, files, jobs) are shared by all applications; a plugin's own service holds only its own logic.
- Platform APIs: everything Studio does is a documented API, also exposed through the CLI and MCP.
Owner and lock
Artifacts shipped by a plugin show an Owner chip and a lock. You do not edit them in place (that keeps upgrades safe); you customize them.
Metadata-first
The same change can be made in a designer, in the JSON tab, from the CLI, or by the AI assistant; all produce the same artifact.
Every designer page uses the same template
What is it, when to use it, concepts, problem statement, real example, all features, step by step, check it worked, security, testing, deployment, common mistakes, related topics. Sections that do not apply yet say Planned so you can see what is coming.