Jump to Content
Product Announcements

Simplifying Google Drive’s folder structure and sharing models

March 26, 2020
Vesa Pirila

Software Engineer, Google Drive

Learn how Drive shortcuts will simplify organizing and sharing files in Google Drive, and what this means for developers who build on the Google Drive API.

Try Google Workspace at No Cost

Get a business email, all the storage you need, video conferencing, and more.


The G Suite team has been working hard to make it easier to organize and share content in Google Drive, and help direct users to relevant files across various drives. 

These efforts have resulted in Drive shortcuts, which are files that act as pointers to other files in Google Drive. Shortcut files can be stored anywhere in Google Drive, including a shared drive or an individual user’s “My Drive.” 

Shortcuts, which are now generally available, will also require those of you who build on the Google Drive API to plan for some upcoming changes. This will ensure your apps continue to work properly, and enable you to take advantage of the latest features in Drive.

Beginning Sept. 30, 2020, it will no longer be possible to place an item in multiple folders; every item will have exactly one location. In the new model, shortcuts can be used to organize content in multiple hierarchies. This simplification of Drive's folder structure and sharing models will result in a change in the way some Google Drive API endpoints behave.

Developers are now able to opt in to the new model to develop and test their apps. We have introduced a new enforceSingleParent request parameter on affected endpoints. To opt in to the new behavior, set its value to true on the requests you make to the Google Drive API. If you choose to opt in ahead of time, the eventual enforcement will cause no further changes to your app’s behavior.

After Sept. 30, 2020, we will begin migrating all items in Drive to a one-parent state. Any other parent-child relationships will become shortcuts in the former parent folders. We will adaptively select the most suitable parent to keep, based on the hierarchy's properties.

The specific changes to the API’s behavior are:

  • You can only add a parent for an item that doesn't already have one. This affects the children.insert (v2), files.update (v2 / v3) and parents.insert (v2) endpoints. You can use the new canAddMyDriveParent capability to check if an item currently has no parents and if the user has sufficient access to add a parent for the item.

  • A request that creates a new item can no longer specify multiple parents. This affects the files.insert (v2), files.create (v3) and files.copy (v2 / v3) endpoints.

  • Moving an item will require access to share the item. Previously, only read access to the item was required. If the requester cannot share an item, they should create a shortcut to it instead. This affects the files.update (v2 / v3) endpoint. You can use the canMoveItemWithinDrive capability to check if the user has access to move an item.

  • An item’s owner will now be able to move their item into a new location, removing all of the item’s current parents, even if they don’t have access to those parents. All access inherited from those parents will be removed. Access that was added directly on the item will be preserved. Previously, the owner could add the item to any folder, causing it to become multi-parented, but this option will no longer be available. This affects the children.insert (v2), files.update (v2 / v3), and parents.insert (v2) endpoints.

  • Any operation that would have previously resulted in an item no longer having parents will now result in the item being parented under its owner’s My Drive. This affects the children.delete (v2), files.delete (v2 / v3), files.emptyTrash (v2 / 3), files.update (v2 / v3), and parents.delete (v2) endpoints.

  • When transferring ownership, the requester will be able to control whether the transferred item is moved to the new owner’s root or kept where it is. If they choose to move the item, any access inherited from the previous parent will be lost, but access that had been directly added to the item will be preserved. The previous owner will always maintain editor access to the item, just as they had prior to these changes. This affects the permissions.insert (v2) and permissions.create (v3) endpoints.

For more information, take a look at our updated developer documentation. We have introduced pages dedicated to single-parenting behavior changes (v2, v3) and the steps app developers need to take to migrate (v2, v3). The API reference has been updated to describe the new parameters in the contexts of each affected endpoint. We hope Drive shortcuts simplify how content is organized and shared, and that these changes enable your apps—and your users—to take advantage of these new features.

Posted in