Skip to content

Access

Access

Control who can open folders, views, tables and dashboards in SAPUGO, what they can do there, and which rows and columns they see once inside.

Access in SAPUGO answers two separate questions. Keep them apart when you plan your system.

  1. May this person open this object, and may they create, update or delete through it? This is decided by the access rules on a folder, view, table, dashboard or database.
  2. Which rows and columns can they see once they are in? This is decided by the access filter the view reads through.

A filter you add to a working view is a third thing: a display convenience. It does not protect data. Anyone who can change the view, or who uses another view with a wider access filter, is not bound by it.

Access rules#

Each access rule names who and what they can do.

Who can be:

  • a User: one person,
  • a User Group: everyone in a group,
  • the Organization: all members of your organization,
  • a Permission: anyone who holds a given organization permission.

What they can do is any combination of Create, Read, Update and Delete. You can pick a preset:

PresetAllows
Full AccessCreate, read, update and delete.
Can Edit (no delete)Create, read and update.
Read & UpdateRead and update, but not create or delete.
Create / ReadAdd new records and read, but not change or delete.
Read OnlyOpen and read, but not change anything.
Custom...Any other combination.

For example, Read without Update shows the screen and refuses edits. Create without Delete lets people add records but not remove them.

Note: The person who created an object always has full access to it, whatever its rules say.

Inherit or custom#

Each object has a Permission mode:

  • Inherit from parent uses the access rules of the folder it sits in. You can still add extra rules on top.
  • Custom permissions uses only the rules set on the object itself, and ignores the folder.

Set rules on the folder when a whole area shares one audience. Then switch to Custom permissions only on the one view that must be tighter or wider than its folder.

To see the final result, choose Show effective permissions. It lists every rule that applies and where each one comes from.

Where to set access#

Folders#

Open the folder's menu in the sidebar and choose Settings. Items in the folder inherit these rules by default. See Folders.

Views#

  1. Open the view and open its view settings.
  2. Choose Permissions.
  3. Pick a Permission mode.
  4. Choose Add ACL, then pick the type (User, User Group, Organization or Permission), who it applies to, and what they can do.
  5. Save your changes.

Tables#

Open the table's page (in the Database section, open the table's menu and choose Settings) and go to the Access tab. Here you see Who has access and can edit the Access rules.

Table access decides who can see the table in the Database section. Most people never need it, because they work in views you put in folders for them.

Databases#

Go to Settings, then Databases, open a database and choose Access Control to decide who can access that database.

Note: Access rules for views, tables and databases are available on the Pro plan and above. On other plans, views are visible to all members of your organization.

Limit rows and columns#

Access rules decide whether someone can open a view. To decide what they see inside it, use access filters:

  • Rows: an access filter for technicians can include only the jobs in their branch.
  • Hidden columns: an access filter can hide a column, such as Price, from a role completely.
  • Read-only columns: a column can be visible but read-only in one access filter, and editable in another. That way one role can see a field that only another role can change.

Assign each access filter to the groups that should use it, and order the filters by priority.

How access works with groups#

Put people into groups, then point access rules and access filters at those groups. Name a single person in an access rule only for an exception.

Organization permissions, such as creating tables, managing workflows or inviting members, are not a substitute for access rules. A person can have permission to create views and still be unable to open a folder whose access rules do not include them.

Plan your access#

Work through these questions for your system:

  • For each folder or section: who can open it, and can they update records there?
  • For each table: which access filters slice its rows, and which groups use each one?
  • Which views must not inherit their folder's rules?
  • Which columns are hidden or read-only for which roles?

An example for a workshop:

ObjectWhoCan do
Workshop folderTechniciansRead & Update
Workshop folderOfficeFull Access
Finance folderBookkeepersFull Access
Jobs table, access filter "My branch"TechniciansRows from their branch, Price hidden

Stuck, or found something missing? Ask the community.

Ask the community

View as MarkdownSuggest an improvement