# Core concepts > Understand the building blocks of a SAPUGO system, from organizations and tables to views, rules, workflows and permissions, and how they fit together. 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. Read more in [Tables](/docs/tables) and [Columns](/docs/columns). ## 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. Read more in [Access filters](/docs/base-views). ## 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. Read more in [Views](/docs/views). ## 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](/docs/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. Read more in [Pages](/docs/pages). ## 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. Read more in [Dashboards](/docs/dashboards) and [Widgets](/docs/widgets). ## Business rules **Business rules** run every time a record is created, changed, deleted or restored. They come in four kinds: 1. **Computation** rules fill in fields, such as a total or a default owner. 2. **Validation** rules check the record and can reject it with a message, or add a warning. 3. **Guard** rules can block an action because of the record's state or the person's role. 4. **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. Read more in [Business rules](/docs/business-rules). ## 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. Read more in [Workflows](/docs/workflows). ## 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](/docs/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](/docs/access). - **Access filters** limit which rows and columns people see once they are in. See [Access filters](/docs/base-views). > **Warning:** 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. ## Related blocks - [Documents](/docs/documents) are PDF templates, such as invoices and delivery notes, that a workflow fills in. - [Webhooks](/docs/webhooks) notify an external system when records in chosen tables change. --- Source: https://community.sapugo.app/docs/core-concepts