Getting started: Projects

The Workplace permissions model

Traditional permissions models are often difficult for average users to leverage and track, leading to misunderstandings concerning who has access to what. Thus, permissions are often assigned to the IT staff to implement and manage.

Workplace makes providing and managing access easy, so that both IT staff and novice end-users can share documents effectively and ensure their data is secure.

It is critical to understand the properties of the permissions model noted below. Please consider reorganizing your data structure to make long-term management of user access simpler. It’s also important to understand these properties to ensure that only authorized users have access to data:

• Permissions are inherited by all folders and files within the project or folder you share with other Workplace users. For instance, if you grant a user Full Access to a project, they will have full access to every folder and file within that project.
• Permissions are granular, meaning permissions can be set on any sub-folder within the data set.
• Permissions cannot be restricted in sub-folders. To share a project or folder with other Workplace users, the owner must grant access to them. Permissions cannot be restricted on a folder. Instead, you should only provide the appropriate level of access required to the specific folders within the folder structure.
• Permissions can be increased in sub-folders. A higher level of permissions can be applied to folders within a project. For instance, Read-Only permissions can be granted for a project and Full Access can be granted for a specific folder within the project. The person with whom you are sharing will be able to read all folders and files within the project as well as have full access to the specific folder to which Full Access permissions were granted. 

  
  Another example of how this can be implemented is that permissions can be granted to a single folder or file within the project file structure - in this example, the team share recipient will be able to see the project. Within the project, they will only see the single folder or file to which they have been granted access. If this folder or file is multiple layers down in the file structure, they will see only the folders that contain the files or sub-folder to which they have been granted access.
• A lower level of permissions cannot be applied than the inherited permission. For instance, if you have given Full Access to a project, you cannot restrict that user to Read-Only or Modify permissions for any of the contents of that project. This also means that access cannot be restricted to a folder or file within a project or folder that has been shared.

Grant only the minimum permissions

We recommend that you only grant the minimum permissions necessary. It's easier to increase permissions later than it is to to correct unintentional or unwanted changes or deletions made by a user who should never have had modification permissions.

Everyone's data is unique, so there will be exceptions to the guidelines below, but they are excellent general advice:

• Create one or more projects for each logical subset of your environment, e.g. by department, by product, by year, etc. or a combination of those.
• Provide either a low level of permissions or no permissions at the project level unless a higher level of access is absolutely necessary.
• Grant increased permissions only at the first, second, and third levels of a project's folder structure. This allows the project owner to have confidential folders or files stored at the project level. Other users will only see a controlled segment of the project.
• Structure your data so that users have Read-Only permissions on the first level (Marketing > Branding) and, for instance, Create & Modify permissions to some second level folders (Marketing > Branding > Work in Progress). This allows the users to work out of the second level folder. While they can still view the higher level folders, they can't change anything.
• Protect your folder structure and file locations by only granting access to the specific folders that users absolutely need to work in. If you share only specific second and third level folders, users are able to access the shared folders but are unable to access the first-level folders you have not shared with them.

An example

You are the VP of Marketing, and you own a project called Marketing. The Marketing team consists of a manager, a designer, and an intern, all of whom are part of the Marketing group. Within the Marketing project we have four folders - Branding, Work in Progress, Prototypes, and Management.

Because the manager requires access to the entire project and fully understands how the project is structured, you choose to give him Full Access permissions for the entire project.

Next, you will grant Read Only permissions for the Branding and Work in Progress folders to the entire Marketing group.

The designer must be able to create new files and folders in the Prototype folders, so you will grant the designer Create & Modify permissions to those folders. The designer also has to be able to create files and folders within the sub-folders of the Work in Progress folder, but you do not want them to be able to create new folders or files in the actual folder.

As you create new folders for current tasks within the Work in Progress folder, you will share these new folders with the designer.

This way, through the mechanism of group sharing within the team, the entire Marketing group (and the intern, who is a member of the group but has not had any direct team shares granted) has Read Only access to the Branding and Work in Progress folders.

The designer is able to see the Branding folder, because they have Read Only access via the group team share. But they are also able to create and modify files and folders within the Prototypes folder, and selected sub-folders within the Work in Progress folder, because they were granted Create & Modify permissions to those locations through a direct team share with them.

The Marketing Manager has full access to the entire project and sees the same content that you, the project owner, sees.

Granting permissions to groups

In order to streamline team shares, we recommend that you organize users into groups using Workplace Online > Team > Groups.

When users are associated with a group, you can then share any given folder with an entire group all at once.

IMPORTANT  Groups should be carefully managed and frequently reviewed to ensure that users added to a group do not gain access to data they should not have access to.

Best practices

• Do not simply give all users “Full Access” to a project. That prevents you from controlling access to sub-folders in the project and can result in users accidentally restructuring your projects and causing confusion for the rest of the team.
• Do create multiple, meaningful sub-folders within the project. Share these sub-folders with users or groups with the minimum permission level required. Users will be able to access the project and the shared sub-folders, but will not be able to amend your first level of sub-folders, allowing you to retain a clean, logical project structure for your team. 

This will support your workflow and will also make it far easier for users to sync only what they need with the Selective sync feature.
• Do not put files in the project, but rather within the project sub-folders. This allows you to maintain a clean folder and file structure. And because you can only share folders, not individual files, this will allow you to effectively manage access to files.

File types not suitable for syncing

Files that are simultaneously accessed by multiple people (such as databases or accounting software) or are frequently updated outside of the control of the user (such as email repositories) should not be synced with cloud file syncing services.

The best practice for these file types is to store them on a locally-accessible drive and then use Workplace's backup feature. For more information, refer to Workplace app Backups tab.

Due to the nature of cloud services and these file types, syncing such files may work but it can also result in unexpected consequences and potential data loss.

IMPORTANT  The following files types will not be synced to Workplace under any circumstances: ~$*,*.tmp,~*.idlk,.ds_store, and all hidden files.

For full details, refer to File types that should not be synced to Workplace.

File counts

If you have any projects that are over 50,000 files (or if you're just curious), please expand the section below.

Why restrict the file count?

The theory

While Workplace has no restrictions on the number of files that can be stored, we recommend keeping the total file count within each project to less than 100,000 files to ensure best performance.

Remember to take into consideration the potential for file count to grow when reviewing you projects.

NOTE  This recommendation applies to individual projects – there are no limits on the number of projects that can be created!

There are a variety of variables (network speed and/or quality, machine specifications, available resources on the machine, amount of data syncing, etc.) that will affect the performance of the Workplace service. In some scenarios you may find performance is affected with fewer than 50,000 files and in other scenarios you may see no performance degradation with much greater file counts.

While it's impossible to account for all the possible variables, we strongly advise that you keep projects small (from a file count perspective) to ensure that all users working on a project enjoy fast, reliable syncing.

Additionally, by splitting the data set into multiple projects, the data set is easier to administer, both with regard to relocating data and (more significantly) setting permissions.

In order for cloud services to operate, a mechanism must track when local changes are made and initiate the syncing process. This is most commonly done using a database of sorts. The number of entries in that database file increases with every file or folder added. The longer the list, the longer it takes to communicate with the cloud service.

Keeping you per-project file count to a minimum ensures that the underlying mechanism functions efficiently and isn’t overloaded.

In practice

The following tips will help you maximize speed and help you get the most out of Workplace:

• Don't drag your entire current working folder(s) into the Workplace folder.
• Evaluate your data set and consider taking advantage of this migration of your data. Treat this as an opportunity to revise your folder structure to make it easier to navigate and to support your team’s workflow.
• Break your folder structure into multiple projects to reduce file count and to make sharing easier. The projects should make sense to you, your team, and the workflow. You may wish to create projects such as “DEPARTMENT_NAME Current Projects”, “DEPARTMENT_NAME Archived Projects”, “DEPARTMENT_NAME Assets” and “DEPARTMENT_NAME Management”.