Forum Discussion
SharePoint 2013 Relationship Possibilities - Need Resource
Hi All,
I am wondering where I can find information to prove a theory that SP2013 does not support a many to one relationship the way ECM tools do (I understand that SP can handle the one to many relationship). In doing initial research a lift and shift approach to moving from an ECM environment will not work. Creating the relationships (foldering structure that was customized by vendor) in the ECM within SP2013 will not work and the LOE to come close in a flat file structure still would not provide the functionality required by the end user. Is there a resource that I can use to demonstrate this to be a truth?
4 Replies
Just like everything in SharePoint, there are many ways to look at a problem and many possible solutions, some of which may be cheap and easy, others expensive and hard.
SharePoint supports content types and metadata which provides a much more flexible approach than nested folders and which could be considered a many to one relationship. Please provide some more details about what you are actually trying to do, and we may be able to provide some suggestions.
- And to be clear, SharePoint is not a relational system :-)...as Dean says, SharePoint is flexible enough to be extended so you can implement what you need but you must be aware of out-of-the-box features and how the platform is designed
All here are a few more known details
- SP2013 out of the box does not support filing documents under multiple folders, the only option is to create a one to many relationship using document metadata to replace the folder structure. (instead of the many to one approach used in current ECM config)
- To do this filing structure has to be flat, in a single repository
- Predefining a relationship hierarchy would restrict users from creating ad-hoc relationships like they do in present workflow (folder/sub folder would then be impossible)
- Custom views and creation would need to occur
- Data mapping to ensure correct migration must happen
- Modification of current workflow/ operational process would be exxpected
We know this much could probably be done.. With that said, there are a list of concerns
- Process can't be migrated to be as simple and customer will have less freedom on document tagging (perceived)
- Worry about in ability to correctly reflect tagging and relationships in the system views, and propagate changes throughout multiple views.
- Potential with new forced process to create confusion and higher % of misfiles
Biggest factor is customer adoption, if the look and feel, and added stress is there and the product does not offer mailability adoption will not happen and the project would be a failure.
How do we address the concerns? It seems like we can force with a lot of work something that will meet the need but possibly negatively impact the user.
Any assistance is appreciated.
