Core concepts · Dokumentacja · SAPUGO Community

A SAPUGO system is the set of tables, screens, rules and processes your organization uses to run its work. You do not get a predefined application. You build the system around your business from the blocks on this page.

Organization#

Your organization is your company's account. People join it by invitation, and you collect those people in groups. The setup screen and settings call it your workspace, and it has its own address such as acme.eu.sapugo.app.

You can belong to more than one organization and switch between them from the workspace menu.

Database#

Each organization has one or more databases. A database is your organization's own isolated store: its tables, records, views, pages, dashboards, rules and workflows all live there. Data never crosses from one organization's database into another's, and all data is hosted in the EU.

Every organization starts with one database. Most teams never need a second one. You can manage databases, backups and restore points under Settings, then Databases.

Tables and columns#

Inside a database, a table is one kind of record: a customer, an order, a vehicle, a meter reading. Each row is one of those records.

Columns are the fields on a record, such as a name, a date, a status or a link to another table. Each column has a type that decides what it can hold and how people edit it.

Access filters#

Nothing on screen reads a table directly. Every screen goes through an access filter that sits on the table and decides which rows and which columns are in scope.

Every table starts with an access filter called Everything, which returns every row and every column. You can add narrower ones, for example "Open jobs in my branch", and route each group of people to the right one automatically.

Views#

A view is a working screen: a table, a kanban board, a calendar or a map. A view always reads its table through one access filter. On top of that, it adds its own filters, sorting and layout.

A view can only narrow what its access filter allows. It can never reveal a hidden column or a row the access filter excludes.

Opening a row shows its record page: the form for that record, plus files, comments, activity and related lists.

Folders and apps#

Folders arrange views, pages, dashboards and other folders in the sidebar. A folder is also an access boundary: items inside it can inherit who is allowed to see it.

The sidebar has three built-in sections:

Workspace holds the screens people work in.
Database lists the tables themselves.
Private holds items only you can see.

You can also give one area of the business its own section in the sidebar, such as Sales, Warehouse or Finance. Read more in Folders.

Pages#

A page is a written document in the sidebar: a handbook, a checklist, a process description. Pages can embed a live view, so the instructions and the list they describe sit side by side.

Dashboards and widgets#

A dashboard is a grid of widgets: charts, single numbers (KPIs) and short lists of rows. Every widget reads through a view, so people only see numbers built from records they are allowed to see.

Business rules#

Business rules run every time a record is created, changed, deleted or restored. They come in four kinds:

Computation rules fill in fields, such as a total or a default owner.
Validation rules check the record and can reject it with a message, or add a warning.
Guard rules can block an action because of the record's state or the person's role.
Side-effect rules create, update or delete other records.

Computations, validations and guards run before the record is saved. Side effects run in the same database transaction as the save. If a required side effect fails, the whole change is undone, so your data never ends up half-updated.

Workflows#

Workflows handle work that takes longer or reaches outside the record: waiting, asking a person to approve, sending an email, building a file, calling another system, or running on a schedule.

A side-effect rule can start a workflow after a change is saved. A workflow never sees a change that was undone.

Use a business rule for a check that must pass before a record is saved. Use a workflow for everything that happens afterwards.

Groups and access#

Three tools decide who can do what. Each has its own job:

Groups name a set of people, such as Technicians or Bookkeepers, and give them organization permissions like inviting members or creating tables. See Groups.
Access rules on a folder, view, dashboard or table say which people, groups or the whole organization may create, read, update or delete there. Items can inherit the rules of their folder. See Access.
Access filters limit which rows and columns people see once they are in. See Access filters.

A filter you add to a view is a convenience for the people using that screen. It does not protect data. To keep rows or columns away from someone, use an access filter.

How the blocks fit together#

Here is how a workshop that books repair jobs might set up SAPUGO:

Tables: Customers, Vehicles, Jobs, Job lines, Parts.
Columns: each job has a status, a date, a link to a customer and a vehicle, a person for the technician, and files for photos.
Access filters: Everything for the owner. "Open jobs in my branch" for technicians, assigned to the Technicians group.
Views: a table of jobs, a board by status, a calendar by appointment date, and a record page with the form, photos and the job's lines.
Folders: a "Workshop" folder holds those screens. Technicians can open it. The bookkeeper's folder is separate.
Dashboard: jobs booked this week and revenue.
Business rules: a validation rejects a job with no customer. A guard blocks edits once the job is done, except for the owner. A computation fills the job total from its lines. A side effect creates an invoice when the status becomes done.
Workflow: started by that side effect, it emails the customer their invoice.

That is the whole shape of a SAPUGO system. Each page in these docs explains one block in detail.

Documents are PDF templates, such as invoices and delivery notes, that a workflow fills in.
Webhooks notify an external system when records in chosen tables change.