Sapugo basics

Sapugo is a system for structured data. Data is only useful in a system when it has a clear shape, a schema, and rules that keep bad records out. Sapugo gives you the tools to build that system for a business, from one person to a large organization.

At the core is your database. In it you build tables, and the tables hold your records. People reach those records through views.

Every table has at least one access filter. When you create a table, Sapugo creates one for you called Everything. Everything has no row filter, so it shows every row in the table. It is the full table, and it stays that way.

To limit what someone can see, add another access filter. In the sidebar, use the + next to the table. Put a filter on that access filter, for example "only rows where the customer is the person who is signed in." Then create the views your team actually opens — a table, a board, a calendar — in the sidebar folders, with that access filter as their parent. Those views inherit the filter. A person working in them only sees the rows the access filter allows.

This is how access stays precise. A new workspace starts open: the people you invite can work. When you need a boundary, you set it with permissions. Who can see a database, a table, a field, or a view is up to you.

A social media agency is a clear case. You are building a system for customers and the posts you publish for them. A customer should see their own posts. They should see nothing that belongs to another customer. An access filter on the posts table does that. The agency sees every customer. Each customer sees only their own rows. Same table, different scope.

Plans are a flat monthly price, so inviting a customer into the system is a normal part of building it. Free includes a small team, Pro a larger one, and Business as many members as you need. What you feel in daily use is capacity. If too many people are active at once, the workspace is rate limited. Free is the tightest. Pro and Business are built for many people working at the same time.

Business rules sit on the data itself. They check a record when it is saved, block a change that should not happen, or write a follow-up value.

A post in that agency system has a status. A guard can say: once the status is Published, the caption can no longer be changed. The row stays as the customer saw it. A side effect on the same save can set Published on to today. The rule runs with the save, so the record and the date stay together.

The workflow engine is where the system starts to run the work. It is a visual programming tool. A workflow can read and write your records, call another system, wait for a person to approve something, and carry a process from one step to the next. A published post can notify the customer. A new request from the inbox can become a row. The tables hold the work. The workflow moves it.

Tables, access filters, permissions, entry views, business rules, and workflows are the core. An entry view is the page you see when you open a record. You design it once, on the view: the form, the tabs, and the related data. Every record opened from that view uses that entry view.

Around that core are an AI assistant, email inboxes, applications, templates, an API, webhooks, secrets, and more. Later posts can take each of those on its own.