Skip to main content
A team groups the people who work together, and a Permission is a named set of powers, such as inviting people or seeing everyone’s work. Both live on the Members page, in its Teams and Permissions tabs. Use them to let a team lead see their people’s work, or a coordinator invite colleagues, without making anyone an Admin. A Project also has roles, such as Project lead, which you fill on its Team tab. See Roles on a Project. Inviting and deactivating people is on Invite and manage people.
Everyone can open the Members page, and Organisation Admins manage it. Only an Admin can create, change, give or hide a Permission.

​
Create a team

A team groups the people who work together, with the Projects and Actions they own. Teams are flat, so they have no manager.
1

Open the Teams tab

Teams appear as cards with the team’s description, its number of members and its number of Projects.
2

Choose New team

Only an Admin can create or delete a team. For everyone else the button is unavailable and gives the reason.
3

Fill in the team

Enter a Team name, and optionally What does this team own? (up to 280 characters), an icon and a colour. Add Members from your Organisation. You stay in the team as its owner.
4

Choose Create team

The team’s page opens.

​
Manage a team

A team’s page shows its Projects, Actions, members and activity, with Edit team and Add members. Admins see every team’s page. A Member sees the teams they are in or own. The ⋯ menu offers View members, View all teams, Invite people, Archive and Delete. Delete moves the team to the Bin and nobody leaves the Organisation. See Bin and restore. A team has owners and members. In the members view, Make owner and Remove owner appear on a member’s ⋯ menu wherever you are allowed to use them. Add members lists the current members with Remove from team. A team’s owners can edit the team and change its people. A person invited to a team sees an invitation on its page, which they Accept or Decline. You can also tick a person in or out of teams from the Teams cell on their row.

​
Create a Permission

A Permission is a named set of powers. Use one to let a team lead see their people’s work, to let a coordinator invite colleagues, or to let one person see every Project, without making them an Admin. A new Permission always starts from a built-in one, so you only change what you need.
1

Open the Permissions tab and choose New Permission

The table lists every Permission with its Type (Built in, or Started from the one it began as), its Assigned people, its Assigned teams and how many Powers it has.
2

Choose what to start from

Start from lists the built-in Permissions, with Members first. Pick one and its powers are ticked for you.
3

Name it

Enter a Name and a Description.
4

Tick the powers

The powers are grouped under People, Projects, Work, Contacts, Companies and Notifications. A power that acts on other people comes in two forms: one for the people in the holder’s own teams and one for everyone, for example See workload of people in their teams and See workload of everyone. The table in How it works lists them all.
5

Assign it

Under Assigned to, add people or teams. Everyone in a team that holds the Permission has it too.
6

Save

Choose Save Permission. The new Permission’s Type reads, for example, “Started from Leadership”.
A Permission with nothing ticked is only a label for a responsibility. You can also give a Permission to someone from the Permissions cell on their row, which ticks the Permissions they hold directly. What a team grants stays with the team. Most powers are about people, Contacts, Companies or the Organisation’s settings, and open no Project. The three Projects powers are different: they give access to Projects. See Give access to every Project. Deleting a Permission takes it from everyone who holds it. Their other Permissions and Access stay.

​
Built-in Permissions

Saphion provides three Permissions in every Organisation. Leadership and People admin are fixed. Saphion keeps them up to date, so when a new power is added to one, every Organisation gets it without anyone editing anything. Their name, description and powers show as read only, marked Protected by Saphion, and they cannot be deleted. To adapt one, create your own Permission that starts from it. You can hide a built-in Permission you never use. Open it, then choose Hide from lists in its ⋯ menu. Its Type then reads “Built in, hidden from lists”. People who hold it keep it, but nobody new can be given it, and it is no longer offered when you start a new Permission or give Permissions to someone. Show in lists brings it back.

​
Change what Members can do by default

Every Member holds the Members Permission automatically. It is the one built-in Permission you can edit. It carries the powers Saphion gives all Members, and it cannot be deleted or given to named people. Open it and untick a power to take it away from Members, then give the power back to chosen people or teams through another Permission.

​
Give access to every Project

The Projects powers let one person open every Project in the Organisation without being added to each one. They cover Projects made later too, and what is filed in them. Sharing, archiving and deleting stay with Managers. On a Project’s Share dialog, the person is listed as “Through” the Permission’s name, at the matching level. They cannot be removed there: take the power away from the Permission, or take the Permission from them.

​
See what a person can do

Choose Access & licences… from a person’s row menu or profile. The panel shows their product seats (Product seats, first), their Organisation role, their teams, the Permissions they hold and their Beacon licence (Standard, Pro or Max, managed by Saphion). Product seats are changed the way they are on their row in the Members table, and how many seats the Organisation has used is under Settings, Usage & billing. Two sections follow:
  • What their Permissions allow lists each Permission they hold with its powers, and how they hold it: Everyone has this (Members), Through a team’s name, Given directly, or Because they own a team.
  • Who has powers over this person says in one line how many Team owners and Permissions reach them. Choose it to see the people whose Permissions reach them.
The owner of a team can see the work, availability, workload and activity of people in that team, and manage its members, without being given a Permission. That is the Because they own a team line. To give someone a Permission here, use the same Permissions picker as on their row in the Members table. To compare what Admins and Members can do, choose Compare organisation roles from the Permissions tab’s page menu.

​
Roles on a Project

A role is a position on a Project, such as Project lead or Contracts Manager. A Permission says what a person can do across the Organisation. A role says who does what on this Project. Open a Project and choose its Team tab. The table lists the Project’s roles, each with its Access level, Who fills it, the Teams that fill it, and where the answer comes from. A role nobody fills reads Unfilled.
1

Open a role

Choose a role’s row, or choose Add to team and pick the role.
2

Choose who fills it

In Who, pick a person. A role that several people can fill takes more than one person, and in Teams it takes whole teams, so everyone in the team fills it. Each choice saves as you make it, with Undo.
3

Or leave it empty on purpose

Choose Leave Unfilled at the bottom of the Who list to say nobody fills it.
Anyone who may change a Project’s team can fill its roles. Everyone else sees the table and the reason they cannot change it. How roles work:
  • A role carries an access level. Whoever fills it gets that level on the Project, with no separate sharing step. Project lead gives Editor. An Admin adds the Organisation’s own roles, such as Contracts Manager, in Settings, under Projects, in the Roles section, choosing a level for each. See Projects settings.
  • Access flows down to Projects filed under it. A person who fills a role on a Project gets that role’s level on the Projects filed under it as well. Filling the role itself does not flow down, apart from Project lead: a Project filed under another takes its parent’s lead until it has one of its own. A parent’s Contracts Manager can therefore edit the child Project’s work, but the child’s own Contracts Manager role reads Unfilled until you name someone there.
  • Work goes to the role holder. When an approval or a template sends work to a role, it goes to whoever fills that role on the Project. If nobody does, it goes to the person who holds that role across the whole Organisation. That person gets no access to the Project this way. If nobody holds it anywhere, the work is refused and names the role, so nothing is approved by default.
  • Share shows roles. In a Project’s Share dialog, anyone who holds a role has a tag with the role’s name after their name, for example “Contracts Manager”. If the role is their only access, their level has no menu: change it on the Roles tab instead of removing them in Share.
  • Opportunities have owners. In CRM an Opportunity owner can edit their own Opportunity. A role like this only raises what someone can do on that record. Whether they can use Opportunities at all still comes from their product seat and Permissions.

​
How it works

​
What each Access level can do

This is the table behind Compare organisation roles. Named Permissions can add the powers marked “With a Permission”.

​
Permission powers

Members hold Create projects, Change due dates, Choose their own notifications and the Contacts and Companies powers until an Admin takes them from the Members Permission.

​
How far a people power reaches

Each power that acts on other people comes in two forms. A person always sees their own work, whatever they hold.