I need to structure a site to store review documents, in line with the following requirements:

  • The following hierarchy is static: A component has documents; documents have reviews; reviews have revisions.
  • Permissions need to be set at a component and a document level and are usually applied to groups but may be applied to individual users. Permissions may be changed.
  • Components or documents may need to be removed.
  • Adding documents, setting permissions, and removing components/documents all needs to be done programmatically via graph.api.
  • There might be a large number of components.

I am thinking of using the following structure:


Does this look suitable? If not, what problems might I run into, and how should I change it to avoid them?

  • See: sharepointmaven.com/… Note: SharePoint has a URL length limit of 400 characters, permissions at the component and document level can be complex. SharePoint already has document management features, see link. Feb 5 at 19:00
  • The URL length wouldn't be exceeded because all of the IDs in the string are GUIDs, so there would be a predetermined length that is within the limit. It sounds like the intended use is to use metadata columns, as per your link, instead of a hierarchical structure, so I probably will use that approach. I don't know why permissions on a folder would be complex? I will research the practical differences between the approaches. Feb 10 at 13:12
  • Searching the site indicates that setting permissions by metadata is not supported, so I need to use a folder structure as per my post. e.g. sharepoint.stackexchange.com/questions/61623/… Feb 10 at 13:17


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.