When starting out with Kahootz and planning your workspaces it’s tempting to map out your project or organisation and create a workspace for each phase or department. This guide will give you some helpful pointers to help you make your decisions, based on our experience helping people to collaborate efficiently.

Workspaces in Kahootz allow you to group information in one place and provide easy access to it to a specific set of users - the workspace members. You can use multiple workspaces to group things together by topic or project or whatever suits your needs. The separation of workspaces and different lists of members allows you to control who can see what.

Alternatively you could put everything in one workspace and group them by folders. You can control permissions using teams within that workspace too; setting which teams can see and modify different items.

In some ways both workspaces and teams would achieve some of the same results; however there are some subtle differences. So what is the best way of choosing when to use separate workspaces, and when not?

Permissions and separations

Separate workspaces keep their members, and therefore the permissions on what they can see and do, entirely separate. Teams exist within a workspace, so if you’re using them to separate you need to make sure that everyone who can create and edit content is getting the permissions right on each and every item. Think about whether your members understand what the teams are for, whether they can set the team permissions correctly, and whether the risk of setting permissions incorrectly is too high.

EXAMPLE ONE: A company with an all staff workspace. If someone from the “Sales” team accidentally saw a “Development” document then it is no big deal, so team permissions are fine. All the staff will know what the teams are and who they involve - the existence and membership of the “Sales” team is unlikely to be a secret.

EXAMPLE TWO: A site is running a procurement exercise with several companies who are each bidding for the contract. Using teams for each bidder would expose too much information and too much risk:  If one bidder saw another’s proposal because of badly set permissions this could be catastrophic to the procurement process.  

Separate workspaces for each bidder gives you a clear “air gap” between the memberships of each and controls the membership and permissions at the workspace level, giving you a guarantee that people can't see the wrong thing or set permissions incorrectly.

The opposite side of membership separation is that if you want the same set of people involved each time, then one workspace might work nicely. If you have ten members of staff involved in all projects then one workspace for those ten, with folders for each project, might be the best approach. That saves you the problem of making sure they’re all invited each time if you did use separate workspaces.

Using Teams to give extra permissions

Teams in a workspace are a good way of granting extra permissions to particular sets of members within that workspace. This will give them more power than normal members, but without giving them the full power of a workspace manager. Teams work well for that kind of “access control” reason, not necessarily as a copy of divisions or sections in your workspace.

EXAMPLE ONE: Your site has an “All Staff” workspace for a small company. There may be no actual difference between what you’d let people in the “Sales” and “Manufacturing” departments do. Even if there are some items that it is only appropriate or relevant for “Sales” to change, you may not need to explicitly stop “Manufacturing” from being able to do so, if they just won’t have any reason to do so naturally.

EXAMPLE TWO: The same “All Staff” workspace might have a database for requesting annual leave. That might have an “approved” column that should only be set by a few people - you could set a “Holiday Approvers” team for the people who can do this; However that’s not a “department” that they’d consider themselves to be in.

Remember that teams can grant extra permissions, not take them away. On the rare occasion that you have an individual you want to stop from editing a document, you can't put them in a “Not trusted” team, and stop that team from editing the document. Instead you’ll have to stop all members from editing the document, and create a “Trusted People” team than can edit the document, and put everybody else in that team.

Kahootz Tip: Remember that teams are specific to the workspace, not the site!

Controlling notifications

As well as permissions - who can see and edit things - think about notifications. Different workspaces allow members to control their own notification settings on a per-workspace basis. If you had separate workspaces for three projects, but had (roughly) the same membership for each, then each individual person could see all the content in all the workspaces. Each member could choose how often they hear about the changes in each workspace separately - maybe immediately for one project and by regular summary for another.

(Remember that people won’t get notified about items they can’t see due to team permissions, but there may be things that you can see, but don’t need to know about as urgently.)

So do you need a workspace or a team?

Ask yourself these questions:

Question one: Is it dangerous if the permissions are set incorrectly, and people see things they shouldn’t? Do you think your members can understand the teams and set permissions correctly each time they create or edit items?  

Answer one: If having people see the wrong information could be catastrophic for you, using separate workspaces avoids this as it puts the access control in the hands of the workspace managers only.

Question two: Have you got a lot of different content or people between projects?

Answer two: If you’ve got 50 different items between the projects, 40 of which are used in the two, but 5 each are different, then team permissions to split the smaller number is easier to manage. If it’s 25/25 each then you’d be involving teams on every object. Similarly for people two workspaces of 10 people each is more manageable than one workspace of 20 people with everything split into two teams of 10. (Even if you have some people involved in both projects, they can easily be in both workspaces.)

Kahootz Tip: Don’t forget, you can change your teams and workspaces as many times as needed, nothing is set in stone! 

Managers can even move content from one workspace to another if required.

If you’re still unsure whether to use teams or separate workspaces to control your permissions, contact our friendly support team.