SharePoint structure for storing customer/project documents

%3CLINGO-SUB%20id%3D%22lingo-sub-737353%22%20slang%3D%22en-US%22%3ESharePoint%20structure%20for%20storing%20customer%2Fproject%20documents%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-737353%22%20slang%3D%22en-US%22%3E%3CP%3EBeing%20a%20SharePoint%20no-ob%2C%20I%20could%20use%20some%20assistance%20with%20creating%20a%20structure%20like%20the%20following%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CUL%3E%3CLI%3ECustomer%201%20with%20associated%20metadata%20(managing%20principal%2C%20main%20customer%20contact%2C%20...)%3CUL%3E%3CLI%3ECustomer-related%20document%201%20(not%20associated%20with%20a%20particular%20project)%3C%2FLI%3E%3CLI%3ECustomer-related%20document%202%20(not%20associated%20with%20a%20particular%20project)%3C%2FLI%3E%3CLI%3EProject%20with%20associated%20metadata%20(project%20code%2C%20main%20project%20contact%2C%20...)%3CUL%3E%3CLI%3EProject-related%20document%201%3C%2FLI%3E%3CLI%3EProject-related%20document%202%3C%2FLI%3E%3C%2FUL%3E%3C%2FLI%3E%3C%2FUL%3E%3C%2FLI%3E%3CLI%3ECustomer%202%20with%20associated%20metadata%3C%2FLI%3E%3CLI%3E...%3C%2FLI%3E%3C%2FUL%3E%3CP%3EThe%20metadata%20defined%20at%20customer%20and%2For%20project%20level%20should%20be%20inherited%20by%20all%20content%20underneath%20that%20customer%2Fproject.%20If%20for%20example%20the%20managing%20principal%20for%20a%20customer%20changes%2C%20then%20all%20projects%20and%20documents%20underneath%20should%20automatically%20be%20updated%20to%20use%20the%20new%20managing%20principal.%20Preferably%20this%20should%20use%20a%20folder-like%20structure%2C%20such%20that%20users%20can%20simply%20add%2Fupload%20documents%20to%20the%20relevant%20folder.%20Based%20on%20the%20metadata%20we%20can%20then%20define%20various%20views%20on%20the%20full%20set%20of%20documents%20(all%20documents%20by%20customer%2C%20all%20documents%20by%20managing%20principal%2C%20...)%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EIs%20this%20possible%20with%20SharePoint%2C%20and%20if%20so%2C%20how%20can%20I%20accomplish%20this%20(preferably%20with%20mostly%20standard%20SharePoint%20functionality)%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ESome%20things%20I've%20tried%20so%20far%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CUL%3E%3CLI%3EDefine%20a%20list%20with%20customers%2C%20define%20a%20list%20with%20projects%20with%20a%20look-up%20column%20on%20the%20customer%20list%2C%20and%20define%20a%20document%20library%20with%20look-up%20columns%20for%20both%20lists.%20Some%20issues%20with%20this%20approach%3A%3CUL%3E%3CLI%3ENo%20folder-like%20structure%3B%20when%20adding%20a%20document%20the%20user%20must%20manually%20select%20the%20correct%20values%20for%20the%20look-up%20columns%3C%2FLI%3E%3CLI%3ELook-up%20columns%20on%20documents%20operate%20independently%3B%20if%20you%20select%20a%20customer%2C%20the%20project%20look-up%20field%20is%20not%20narrowed%20down%20to%20only%20projects%20for%20that%20specific%20customer.%20Likewise%2C%20if%20you%20select%20a%20project%2C%20this%20doesn't%20automatically%20update%20the%20customer%20field.%20Potentially%20this%20could%20be%20solved%20using%20%3CA%20href%3D%22http%3A%2F%2Fsympmarc.github.io%2FSPServices%22%20target%3D%22_blank%22%20rel%3D%22noopener%20nofollow%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttp%3A%2F%2Fsympmarc.github.io%2FSPServices%3C%2FA%3E%2C%20but%20if%20possible%20I%20want%20to%20refrain%20from%20using%20such%20custom%20solutions.%3C%2FLI%3E%3CLI%3EAdditional%20fields%20to%20be%20displayed%20cannot%20refer%20to%20look-up%20columns%20(i.e.%20based%20on%20a%20selected%20project%2C%20you%20cannot%20display%20metadata%20from%20the%20corresponding%20customer%20list%20item)%3C%2FLI%3E%3C%2FUL%3E%3C%2FLI%3E%3C%2FUL%3E%3CUL%3E%3CLI%3EDefine%20custom%20'Customer%20(Folder)'%20and%20'Project%20(Folder)'%20content%20types%20inheriting%20from%20the%20Folder%20content%20type.%20This%20allows%20for%20associating%20metadata%20on%20these%20content%20types%2C%20but%20I%20haven't%20figured%20out%20yet%20how%20the%20'Project'%20and%20(custom)%20document%20types%20can%20inherit%20the%20metadata%20from%20the%20parent%20folder(s).%3CUL%3E%3CLI%3EThere%20are%20some%20possibilities%20to%20define%20default%20metadata%20values%20on%20folders%2C%20but%20I%20haven't%20figured%20out%20how%20to%20configure%20these%20default%20values%20based%20on%20the%20metadata%20values%20already%20defined%20on%20the%20folder%20(only%20examples%20I've%20seen%20use%20hard%20coded%20default%20values%2C%20so%20you%20would%20need%20to%20define%20the%20same%20values%20twice%3B%20once%20as%20folder%20attributes%2C%20and%20once%20as%20default%20metadata%20values%20for%20each%20folder).%3C%2FLI%3E%3CLI%3EEven%20if%20it%20would%20be%20possible%20to%20dynamically%20determine%20the%20default%20values%20based%20on%20folder%20metadata%20values%2C%20this%20wouldn't%20automatically%20update%20the%20managing%20principal%20for%20all%20projects%20and%20documents%20if%20the%20managing%20principal%20is%20changed%20at%20customer%20level%3B%20the%20default%20values%20would%20only%20be%20used%20when%20adding%20new%20projects%20or%20documents.%3C%2FLI%3E%3CLI%3EThe%20contents%20of%20the%20'New'%20menu%20are%20defined%20are%20library%20level%2C%20meaning%20that%20users%20could%20add%20documents%20at%20root%20level%20(not%20associated%20to%20any%20customers)%2C%20or%20could%20create%20an%20incorrect%20structure%20like%20Project-%26gt%3BCustomer-%26gt%3BCustomer-%26gt%3BProject-%26gt%3BDocument.%3C%2FLI%3E%3C%2FUL%3E%3C%2FLI%3E%3C%2FUL%3E%3CUL%3E%3CLI%3EDefine%20custom%20'Customer%20(DocSet)'%20and%20'Project%20(DocSet)'%20content%20types%20inheriting%20from%20the%20Document%20Set%20content%20type.%20This%20allows%20for%20associating%20metadata%20on%20these%20content%20types%2C%20and%20share%20this%20metadata%20with%20child%20items.%20However%3A%3CUL%3E%3CLI%3EDocument%20sets%20cannot%20contain%20other%20document%20sets%2C%20so%20'Customer%20(DocSet)'%20cannot%20contain%20any%20'Project%20(DocSet)'%20items.%3C%2FLI%3E%3C%2FUL%3E%3C%2FLI%3E%3C%2FUL%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAny%20suggestions%20on%20how%20this%20can%20be%20implemented%2C%20or%20better%20ways%20for%20organizing%20such%20data%20in%20SharePoint%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-737353%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EDocument%20Library%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EFiles%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3ELists%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3ESharePoint%20Online%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EUsage%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E
Highlighted
Visitor

Being a SharePoint no-ob, I could use some assistance with creating a structure like the following:

 

  • Customer 1 with associated metadata (managing principal, main customer contact, ...)
    • Customer-related document 1 (not associated with a particular project)
    • Customer-related document 2 (not associated with a particular project)
    • Project with associated metadata (project code, main project contact, ...)
      • Project-related document 1
      • Project-related document 2
  • Customer 2 with associated metadata
  • ...

The metadata defined at customer and/or project level should be inherited by all content underneath that customer/project. If for example the managing principal for a customer changes, then all projects and documents underneath should automatically be updated to use the new managing principal. Preferably this should use a folder-like structure, such that users can simply add/upload documents to the relevant folder. Based on the metadata we can then define various views on the full set of documents (all documents by customer, all documents by managing principal, ...)

 

Is this possible with SharePoint, and if so, how can I accomplish this (preferably with mostly standard SharePoint functionality)?

 

Some things I've tried so far:

 

  • Define a list with customers, define a list with projects with a look-up column on the customer list, and define a document library with look-up columns for both lists. Some issues with this approach:
    • No folder-like structure; when adding a document the user must manually select the correct values for the look-up columns
    • Look-up columns on documents operate independently; if you select a customer, the project look-up field is not narrowed down to only projects for that specific customer. Likewise, if you select a project, this doesn't automatically update the customer field. Potentially this could be solved using http://sympmarc.github.io/SPServices, but if possible I want to refrain from using such custom solutions.
    • Additional fields to be displayed cannot refer to look-up columns (i.e. based on a selected project, you cannot display metadata from the corresponding customer list item)
  • Define custom 'Customer (Folder)' and 'Project (Folder)' content types inheriting from the Folder content type. This allows for associating metadata on these content types, but I haven't figured out yet how the 'Project' and (custom) document types can inherit the metadata from the parent folder(s).
    • There are some possibilities to define default metadata values on folders, but I haven't figured out how to configure these default values based on the metadata values already defined on the folder (only examples I've seen use hard coded default values, so you would need to define the same values twice; once as folder attributes, and once as default metadata values for each folder).
    • Even if it would be possible to dynamically determine the default values based on folder metadata values, this wouldn't automatically update the managing principal for all projects and documents if the managing principal is changed at customer level; the default values would only be used when adding new projects or documents.
    • The contents of the 'New' menu are defined are library level, meaning that users could add documents at root level (not associated to any customers), or could create an incorrect structure like Project->Customer->Customer->Project->Document.
  • Define custom 'Customer (DocSet)' and 'Project (DocSet)' content types inheriting from the Document Set content type. This allows for associating metadata on these content types, and share this metadata with child items. However:
    • Document sets cannot contain other document sets, so 'Customer (DocSet)' cannot contain any 'Project (DocSet)' items.

 

Any suggestions on how this can be implemented, or better ways for organizing such data in SharePoint?

0 Replies