Press Play on the video player above to view this training video. The video script is presented below if you prefer to read.

It's easy to dismiss permissions as simply a way to give users access to parts of your folder tree, but that misses some of the most interesting aspects of system design. In fact, before we go further, let's take a quick look at how easy it is to assign a permission to a user.

Here we are logged in as a user who has no permissions yet, not much to see. Not much to do. But let's hop over to our administrative user and change that. [see video] This is simple through the Files.com interface.

The first thing we need to look at is where in the folder tree we want these permissions to start for this user. Let's choose the video tutorials folder. The next thing is: which user or group do we want to grant permissions to? So, let's add a new permission, and let's choose our newuser2196. And for now, let's just say we're going to grant full permission to this folder. Open this menu, and you can see that this user can be an administrator of this folder, can have full permission, read-write, only read, only write, or list just to see what is in this folder and sub folders, or history permissions allowing this user to see the history logs or the audit logs that are associated with this folder. So for now, to keep it simple, we're just going to grant full permission. And we click add.

Now, if we refresh, this user has a very different experience. You can also see that as an administrator, by clicking on the permissions button at any given folder, you can see who has permissions to this folder, and what permissions they have.

With the permissions that we've granted this user, they can navigate in and out of folders, upload and download files, all the operations that a user would typically do: update, delete, move, and copy. If we want to remove permissions from this user, it's as simple as clicking on these permissions, [web interface - see video] and they're all selected because they're part of the full permissions, and we can click revoke.

Now if we refresh over here, we don't have permissions to any folder anymore. So, now let's navigate to a an interior folder, and instead of setting permissions to this folder, we're going to set permissions to this other folder. And we'll see how that's different.

So we go back to our permissions button, click on that, we can see who has permissions; this user is not included in this list. So, now we're going to add a new permission. Choose our user again, and this is the same user, and let's say we're going to just add list permission this time, and we're going to add only for this folder only and not any subfolders. Let's check this box. So, any sub folders that are added in here, this user will not be able to access for listing purposes. Now we add this permission. You can see that this permission now has a slightly different icon. This dot indicates that this is non-recursive.

So first, let's go over to this user and refresh. We can go into video tutorials. We see we only have access to the European operations folder. Let's go ahead and list. Now we can see the same files that are appearing on this side for our administrator, but let's create a new folder and call it folderA. Let's copy a few files into folderA.

Remember, we granted non recursive permissions to newuser2196, so if we go back and reload this folder, we can see that we can list the contents of this folder but we don't have access to folderA, so we can't see that folder is there, nor can we list the contents. Now let's go back and change this one more time. We're going to remove that permission. Now we're going to add it again, and this time we're going to add it as recursive.

Now there's no dot on that icon. And now if we refresh, we see folderA, and we can list the files that are in folderA.

Since Files.com has a built-in granular permissions model, setting permissions becomes, in effect, a design tool that allows you to create guides and structure that make your system stronger, smarter, and more productive.

Let's take a look at how that can happen.

But first let's talk about the principle of least access. This principle states simply that a user should have the minimum permissions needed to accomplish their tasks. This approach provides better security, and makes it less likely that a user will inadvertently lose or compromise data. A simple example would be a user who needs to know and report on which files are present in a folder in order to complete their tasks. Providing that user list permission like we just did, only allows them to see which files are there but does not allow them to accidentally delete any files. So for instance, if we try to check a file, I have no way to delete. And there's no mechanism here that would allow me to do that.

In contrast, following a practice of providing all users full permission by default, leaves open the possibility that a busy team member clicks too fast, or without looking, and accidentally destroys a file.

Believe me, if that happened to you, you wouldn't be the first. But why not use the principle of least access to avoid that.

Another benefit of using that more secure approach is that by using the available permission options, rather than granting everyone full access by default, you've turned permissions into a structural tool to enhance your system design.

Let's talk for a second about file flow.

Files come in, files are stored, files go out. In some simple workflows, your Files.com site might act like a warehouse, where you keep your files until someone needs that data. But in other cases, and more commonly in our experience, files need to be acted upon and referenced by multiple parties at multiple points in a complex process. Most often, more than one team is involved, and the touch points include both human and automated users.

Should all of these touch points or users have full permission set to perform any action on those files? Absolutely not. Permissions need to be set appropriately, following least access for each user's collection of tasks.

When files need to migrate through a process to help the process work, we can use permissions to guide their direction of flow. For instance, users in groups that have read permission can pull files from a folder. Users and groups that have write permission can push files into a folder. Those with read permission for folderA and write permission for folderB can perform a copy from folderA to folderB.

Those with read and delete permission for folderA and write permission for folderB can move a file from folderA to folderB. Extending this simple example, you can see that permissions determine which users or groups are able to move files in which directions.

So how do you use an example like that in a system design sense? You can think of it almost like plumbing. You have a resource, your data, that needs to move through a process to create its value, and like water through pipes, in order to generate the value you intend, it needs to follow a design shape, so you can predict its state at each step along the process and at the point of value delivery.

Let's take a hypothetical.

Let's say you have 15 inboxes where anonymous users can upload files. We often see this scenario in use cases by universities and municipal governments, pretty much any organization that has to serve a constituency.

Each of the inboxes is for a particular purpose, expecting particular types of files. You have an intake team that performs initial verification of the uploaded files. That intake team needs to verify the files and advance them into categorized folders for the next team to review.

The review team is notified of files arriving, perhaps based on category, for specific roles within the team by email notifiers, so they know to go to their category folder to retrieve them with categorization happening at intake.

You can see we're starting to create a funnel shape here. We have fewer categories than inboxes, and the goal at this step is to present the review team only with vetted and properly categorized files to review.

Another important goal is that we don't want any submissions to fall through the cracks or be lost. How would permissions help us meet these goals for this part of the process? The intake team needs read permission for all of the inboxes so that they can see and vet the submissions. To make sure that no one from the intake team accidentally loses a file, we would avoid giving them delete permission. And, since they are not adding files to the inboxes, they do not need write permission. They do however, need write permission to the next layer of folders, where they will advance the submissions for the review team.

So the intake team can see and evaluate files in the inboxes and copy them with their read permission to the next layer of folders where they have write permission. Since they can't delete files from the inboxes, no file is lost.

But wouldn't that clutter up the inboxes with duplicates and over time make new submissions harder to sift through? Sure. But that's an easy one to solve with web hooks and the REST API.

What you do is set up a web hook in each of the inboxes as well as the target folders for the next layer. The web hook fires on the read action from the inbox, and then the create action to the target folder and triggers a script that uses an API key owned by a bot user with delete permission to the inboxes.

And note that we do have a separate video on the use of web hooks, which I encourage you to check out.

Now, in our plumbing metaphor, this functions like a one-way check valve. The file is only deleted from the inbox when it has been confirmed copied into its new location, and is deleted automatically by a bot user based on the path provided by the read web hook. Using permissions, the submissions can flow only in one direction, can't go back, and can't be deleted until they are confirmed in their new location.

How about the files that don't pass muster in the inboxes? We don't want to leave them in there to create clutter. That's also an easy one. Provide the intake team with a remove folder at the same level as the target folders and give them write permission to that folder and set the webhooks just as if it were another target folder only for the remove folder. Set a folder behavior to automatically expire the files after 30 days, or whatever number of days makes sense. This automatically clears the clutter but still gives you 30 days to double check the discarded files should that be necessary in your process.

So this leaves us with the files advanced to the appropriate review folders for the review team. Let's say the review team is going to review these files and then further advanced them to the next level for the processing team. We're continuing the funnel design by giving the review team write permissions to fewer target folders than they have read permissions for.

Let's say their review results in these files going through either process A or process B. Let's also say that both processes will change the files. But we want to keep the original secure for a period of time for reference. So we will use a variation of the one way check valve. Rather than using web hooks and the API to delete the files as soon as they are copied to the process folders. We'll use that same combination with an API call to copy the files instead to a holding folder. To perform the copy the API key would need to have at least read and write permission.

If it makes sense for the process, we could put something like a 90 day file expiration on this holding folder to automate the housecleaning. Now, the process team needs full permission to their process folders, because they're going to be making edits to the files. They also need read permission to the holding folder, so they can refer to the original files if they need to. But we don't want them to be able to change those originals.

When the processing team is done with their processes, they can advance the files to an authorization folder where they have write permissions but not delete permissions. This continues the direction of flow through the funnel, and maintains the one-way check valve.

Once they upload the finished files that are waiting for authorization, they cannot overwrite them or delete them because they do not have delete permission to the authorization folder. The authorization team needs read permissions to the authorization folder so they can view the files and give them the Okay.

Let's say that this process of content creation and review has resulted in outputs of some sort, like reports that are output as PDFs. At the end of the line, these reports need to be distributed to a population. The authorization team has the responsibility to sign off on the reports and final product produced by the process team and then distribute them to the end users. They can do this with their read permission to the authorization folder and write permission to a distribution folder.

If the population that needs the reports is not a credentialed population, or is anonymous, which is normally the case in the workflows we see in municipal governments and customers of that type, then the distribution is likely to be by a sharelink URL that is given out to the population. The share link is to the distribution folder itself, so when the authorization team copies the processed report file from the authorization folder to the distribution folder, it is instantly available to the audience. And depending on the nature of the file content, maybe the share link is protected by a password.

We have another video in this series that deals specifically with share links that I also encourage you to watch.

We've talked about these structures referring to individual user permissions so far, but the most efficient way to leverage these ideas is with group permissions. When we speak in terms of teams, that naturally lends itself to the idea of groups. If you build your permission structure around groups, then managing appropriate access becomes a much simpler matter of making sure your users are members of the right groups. In fact, we have a feature that allows you to manage all permissions via groups. Enabling this feature on your site means that your existing users with permissions still have those permissions, but any changes would have to be made through groups, and any additional permissions added to your site would only be done through the group context.

We have a separate video also talking more specifically about using groups on Files.com, so be sure to check that one out as well.

We hope that this discussion of permissions as a design tool has left you informed and opened doors to new ideas about how you can design processes that secure your operations and help them be more reliable and efficient.

If you have any questions, please feel free to Contact Us or give us a call at 1-800-286-8372.