Roles and Permissions

Finpilo comes with three user roles, and you can add roles of your own. Owner and Admin have identical permissions in the interface, except that only an Owner can give or take the Owner role. Member has restricted access to configuration and management features.

A role is a set of permissions, and every screen shows or hides its buttons and tabs from the permissions the roles you hold cover. Finpilo checks the same permissions when you save, and when an AI assistant or the API acts for you. The tables below show what each role sees.

Role overview

Roles per entity

A person is added to specific entities, and each role they hold applies where it is given:

• Whole workspace. The role counts in every entity, one added later too. Owner and Admin are given here.
• One entity. The role counts in that entity only. A Member is Member on each entity they are added to.

Someone who is Approver in SIA Alfa and Viewer in SIA Beta moves documents in Alfa and only sees them in Beta. A person sees only the entities they are added to, unless they hold a role for the whole workspace.

Workspace settings count only from a role held for the whole workspace: fields, lifecycles, workflows, integrations, integration logs, groups, roles, people, API & AI access and usage. Given on one entity, these permissions give nothing.

The History tab of a document or a dimension shows only with History › See in that entity. Importing dimension values needs Add and Edit, because an import can change values that are already there.

A group holds roles the same way, for the whole workspace or on an entity, and everyone in the group holds them there. When a status move, an approval or a notification names a role, it means the people who hold that role in the document's entity.

Roles you create

Owner, Admin and Member come with every workspace. You can also have roles of your own, such as "Approver" or "Read only": a name plus the permissions you tick in a grid. Each area has See, Add, Edit and Delete, and documents also have Move and Share. Ticking any box of an area also ticks its See, and locks it while that box stays ticked.

Roles are on Workspace Settings → People → Roles. Add Role makes one. A role's ⋮ in the list has Duplicate, which starts a new role with the same boxes ticked. A copy of Owner has every box ticked but the right to give Owner, which stays with Owner. Open a role to rename it or change its boxes, then click Save. The grid has two parts. The first counts in the entities the role is given for. The second counts only when the role is given for the whole workspace. Delete Role is in the ⋮ at the top of a role's page. Owner opens with every box ticked and nothing to change. Your AI assistant can do all of this too.

• A person can hold more than one role, each for the whole workspace or on an entity. What they may do in an entity is everything their roles there and their whole-workspace roles allow together.
• A group can hold roles too. Everyone in that group then holds those roles, where the group holds them, for as long as they are in it (see Groups).
• An invitation gives someone their roles from the start, for the whole workspace or entity by entity, and puts them in groups. A person's page changes them later (see Workspace Settings). Your AI assistant can do this too.
• A status move, an approval, a notification and a document lock can each be limited to a role, in the same list where they name people and groups. A move limited to some people belongs to them alone. An Admin it does not name cannot make it either.
• Owner cannot be changed or deleted, no other role can hold the right to give or take Owner, and a workspace always keeps one Owner. The roles Finpilo ships cannot be deleted.
• You cannot give a role a permission you do not hold yourself, where you give it. The message names the permissions that are missing. Adding someone to a group takes holding what the group's roles give. Renaming a role or a group, unticking a box or taking someone out of a group never needs that.
• A role somebody holds, or that a group, lifecycle or workflow still names, cannot be deleted. The message says what is using it, so you can change that first.
• A deleted role is kept aside. It gives nothing and leaves every list. Filter Roles by Deleted to find it. It opens read-only, and Restore Role at the top of its page brings it back.

Why someone can do something

Ask your AI assistant what a person can do and why. The answer lists every permission they hold, the role it comes from, the group that role comes through when a group gives it to them, and the entity it applies in. That is the quickest answer to "why was that refused".

Who sees which documents

Three things decide it, and nothing else does.

1. The roles, entity by entity. A role that can see documents in an entity sees that entity's documents. Without it a person sees there only the documents given to them.
2. Access given to a document. A Change Access step on a status move, or in a workflow, gives the people, groups or roles it names a level on that document: View, Edit, Manage, or a level your workspace made. The access stays with the document until another Change Access changes it for that person. Choose No access instead of a level to take back what Change Access and sharing by hand gave those people on the document. An approval and a notification give the people they ask View, so they can open what they are asked about. Uploading or emailing a document gives no access by itself. A group is given access as a group, so someone who joins it later sees the document too.
3. A status's access rule. A status can say who may see its documents, optionally only when the document matches a condition, for example "supplier is Amber Housing". While a document is in that status and matches, only the people the rule names see it, at the level the rule gives them. Everyone else does not, including people given access before and an Admin the rule does not name. When the document moves on, or its data no longer matches, the rule no longer applies.

Who may share. Sharing a document, changing or removing a share, and putting its access back to default all need the Share permission on that document. Owner and Admin hold it. Member does not, and neither does anyone who can only view or edit a document. You can tick Share on any role of your own, and the Manage level carries it, so someone given Manage on one document can share that document. A document is shared with people and groups, never with a role. Nobody can give more access than they hold themselves, nobody can change or remove a share above their own level, and nobody can be given access to an entity they are not a member of. An approval that names a person who is not a member of the document's entity fails and says who. An approval that names a group asks only its members who can open the document's entity, and the finished step names the others.

Example: people see only their own documents. Give their role no access to documents, and add a Change Access step to the first move after Uploaded that gives Submitted by Edit. Each person then sees the documents they uploaded or emailed in, plus anything shared with them or they are asked to approve.

You share a document with people and groups. A role gets access to a document only through a Change Access step. To share a document, open it and choose Share in its ⋮ menu. The window lists who has access and why. Add people or groups under Share with, choose their Access, and select Save. A row shared here or by a Change Access step has its level in a list, where you can change it or choose Remove access. Nothing changes until you select Save. Cancel drops it all. Save becomes available once you change something. After Save the window stays open and shows who has access now, and Close closes it. To share several documents at once, tick them in the list and choose Share in the bar. Share appears only if you may share. Nobody gives more than they hold. Your AI assistant can do the same. Taking one share off, or putting access back to default, removes what Change Access and sharing gave, for that one or for everyone. The answer to who can see a document also says whether you may share it, the levels you may give, whom you may give it to, and which shares you may change or remove. What an approval or a notification gave stays.

Setting it up. Open a status in the lifecycle editor. Under Lock, switch the lock on. Add a condition under Only When to lock only the documents that match, and name who Can Still Edit. Under Who Sees It, choose Add Rule, then give the rule its condition, its People and their Access. A status can have several rules. A document that matches more than one is seen by the people of each. Add a Change Access step to a move or a workflow, and choose its People and Access.

Who can edit a document

A person can change a document when two things are true.

1. They may edit it. Their role lets them see and edit documents in its entity, or they were given Edit or Manage on the document (by sharing or a Change Access step). While a status's access rule applies, only the access that rule gives counts.
2. Its status is not locked for them. A status with Lock on holds everyone, admins too, unless it names them, a group of theirs or a role of theirs under Can Still Edit. Anyone else must first move the document out of that status, if that move is theirs to make.

Your workspace's own workflows can still write onto a locked document.

Permissions by area

Sidebar navigation

Dashboard

No permission restrictions. All roles see the same content.

Documents list

Everyone sees the documents they may see (see Who sees which documents), and can search, filter, upload and export them.

Document View

Entity Management

Partners

Dimensions

Document Types

Views

Workspace Settings

Entity Integrations tab

User Settings (personal)