How the pieces fit together to make a complete application

What this page is for

Spark ERP gives you separate tools: entities, pages, rules, workflows, jobs, notifications, integrations, permissions, AI. A real application uses most of them at once. This page shows what each tool is responsible for, how they hand work to each other, and how one business action, a leave request, travels through all of them.

The shape of the platform

 Person ── Page (blocks, forms)
              │  reads and writes through
              ▼
        Data services / data views / entity API ── permissions checked on every call
              │
              ▼
        Entity engine  ──►  Rule engine ──► Action engine ──► (set a value, reject, call a service, notify, start a workflow)
              │                                                   │
              │ record changed (event)                            ▼
              ├──────────────► Workflow engine ◄── triggers: record change, schedule, API, webhook
              │                      │ human tasks, timers, service nodes
              │                      ├──► Notifications (in-app, e-mail, SMS, Slack, Teams)
              │                      ├──► Integrations (connectors and flows to other systems)
              │                      ├──► AI nodes (prompts, knowledge, agents)
              │                      └──► Records again (create, update)
              ├──────────────► Audit trail
              └──────────────► Jobs (scheduled sweeps over records)

Everything is JSON you design in Studio. Nothing needs a program to be written for the usual cases, and everything you design is packaged in a plugin so another environment can install it.

What each tool is for

Tool	Responsible for	Does not do
Entity	The record type: fields, types, keys, indexes. Creating one gives you a database table and a full create, read, update, delete API	Business decisions
Data provider, view and service	Named, permission-filtered reads and writes that pages use, instead of raw tables	Screens
Query engine	Paging, filtering and sorting for any grid or KPI, with no code	Changing data
Validation	Refusing a bad value, reused by forms and entities	Multi-step processes
Rule	One moment in a record's life (before or after create, update, delete): reject, set a value, start a workflow, run a service	Waiting for people
Action	The verbs rules and pages use: set, notify, start a workflow, execute a service, recompute a balance	Deciding when to run
Workflow	A process over days across people: approvals, deadlines, escalation, parallel work, waits	Showing screens
Job	Work on a clock over many records: remind, expire, generate, sweep	Reacting to a single save
Notification	Telling someone through a channel	Deciding who and when
Integration	Talking to other systems with stored connections and secrets	Business rules
Page, form, block	What people see and click, bound to data	Storing or enforcing anything
Permission	Who may see or do each thing, checked on the server	Hiding by itself
Plugin	Packaging all of the above to install in any environment	Running logic
AI	Drafting, answering, classifying, acting through tools you allow	Bypassing permissions

A rule of thumb for choosing: pages show, entities store, rules react to a save, workflows wait for people, jobs wait for the clock, integrations talk outside, permissions decide who.

One action, end to end: a leave request

Anna submits two days of leave.

1. Page and form. A form bound to the leave_request entity. Required fields and dropdowns come from the entity; the form can also hide or lock fields by role (field permissions).
2. Permission. Anna holds create on leave_request. A record permission means she only sees her own requests later in the grid.
3. Validation and rule, before save. A validation checks the dates are in order. A rule BEFORE_CREATE rejects the request if she has less balance than days asked, with a clear message. The save is refused before anything is stored.
4. Entity engine stores the record. An audit entry is written (who, what, when).
5. Rule, after save. An AFTER_CREATE rule raises the pending days on her leave balance (a ledger recompute) and starts the leave-request workflow.
6. Workflow. Stage manager: a human task for the manager named in the request's data (${context.managerEmail}), with a two-day SLA that escalates to HR. If the total is more than three days, the next stage hr also applies (a conditional transition).
7. Notification. On entering each stage, an in-app notification node tells the approver. If the SLA lapses, the escalation reassigns the task.
8. Decision. The manager approves in the inbox. The workflow moves on and, at the end, a record node posts a LEAVE_USED ledger entry; that recomputes her balance (pending down, used up).
9. Integration. A Run integration node tells the payroll system, using a stored connection with its secret held by the platform.
10. Job. A nightly status-date sweep marks requests as completed after their end date; a reminder sweep nudges approvers who have waited too long.
11. Events and audit. Every step is in the workflow history and the audit trail. Another plugin can subscribe to the same events.
12. Page again. Anna's grid, filtered by her record permission, now shows the request as approved, and a KPI card on her dashboard shows her new balance.

No step needed code. Each is a JSON artifact you made in a designer.

The balance, workflow and sweep steps are how the HCM Leave application is built. The payroll call in step 9 is an example of what you would add.

The seams between tools

These are the places where one tool hands work to another. Knowing them tells you where to look when something does not happen.

From	To	Through	If it does not happen, check
Page	Data	A binding to a data service, view or the entity API	The binding scope and name; the person's permission
Save	Rule	The rule's trigger (BEFORE_CREATE, AFTER_UPDATE...) and conditions	The entity name, trigger, and condition values
Rule	Workflow	The start workflow action	The workflow is published; the actor holds submit on it
Record change	Workflow	A record trigger in the workflow's metadata	The trigger's entity, event and filter; the loop guard (changes made by the workflow engine itself do not start workflows)
Workflow	Records	record.* nodes	The node's entity and id; the configured actor's permission
Workflow	People	Human tasks, candidate approvers (role, ${context.x}, ${rule.x})	The approver value resolved (a missing context key stays as literal text)
Workflow	Other systems	integration.run, notification nodes through connectors	The connector exists and its secret is set
Clock	Records	A job (sweep) or a workflow schedule trigger	The job's config row; the schedule's cron and time zone
Anything	Audit	Platform events	Nothing to set up; it is automatic
Design	Another environment	A plugin package	The artifact is in the plugin and published

Where each piece lives in Studio

Piece	Studio screen	Reference
Entities and fields	Data model	Data Model
Providers, views, services	Data	Data providers, views, services
Pages, forms, blocks	Page Designer, Form Designer, Blocks	How a screen is built, Block catalog
Rules, validations	Rules, Validations	Workflows, rules and validations
Workflows	Workflows	How workflows work
Jobs	Jobs	Jobs and scheduler
Notifications	Communications	Events and automation
Integrations	Integrations	Integrations and connectors
Permissions	Security	Permissions
AI	AI Studio	AI guides
Packaging	Plugin Designer	Plugin Designer

Build order that works

1. Entities first: the nouns of the application.
2. Security: roles and permissions, because "no rule" means allowed.
3. Screens: grids, forms and detail pages bound to the data.
4. Behaviour: validations, rules and workflows.
5. Insight: dashboards and reports.
6. Quality: test cases, simulate workflows, check as each role.
7. Ship: package as a plugin and install in the next environment.

The Build a complete application chapters walk through exactly this order with a worked example.

Where next

• Page data flow
• How workflows work
• Permissions