Forum Discussion
What is the plan for "modern" Document Sets?
- Its too early to put specifics on the roadmap - but we will update document sets. We are not being "classic Microsoft" here - there is a steady stream of requests for docsets (along with other parts of classic ECM) and I've never pretended otherwise. Fear is not part of the plan. I hope to be able to give roadmap updates at SPC or Ignite this year, if that helps.
Setting aside the levity, we have been working to balance and prioritize innovation with updates to classic features that remain fully supported. We know that sometimes this takes longer than some customers would like, and hope that the modernization announcements, including docsets, this month will be worth the wait.
Certainly hope so. At the same time, the levity does relate to real points. In particular (and I will accept that the announcement management has improved via roadmap) we were initially lead to believe (in these forums - some now gone) that the update would be soon and some of us made
commitments based on that. Even in the new improved roadmap world, precious little was said about document sets until quite recently but you must have realised that having a completely different interface in 90% of the product would have been a significant issues for most clients and hiding behind the "you could use classic" or "we haven't taken away functionality" [document sets still work like the did) grows a bit weak after a few year. You will have read my concern (and others) that perhaps you were considering dropping the functionality (as has so often happened with features that don't get updated in MS world). I really think document sets could have had more information on the roadmap at an earlier date - even if it was just to say that you weren't dropping it.
Thank you for your comments though as at one point it seemed like they were the only info.
The roadmap didn't mention document sets until 17th of September this year and still has little to say.
- Featured ID: 33761
- Added to Roadmap: 9/17/2018
- Last Modified: 12/26/2018
- Thank you for a brilliant reply - I will have to read more carefully and digest. In answer to your first question, it is a small organisation without any IT skills. (Except me as a volunteer [I am an selected councillor & currently Mayor but not in any paid role] and although I have had 35 years in IT with many years as an internal vendor in MS, my area was networking and platforms [I taught MS support staff mostly all around the world] - SharePoint is not my subject.)
Like you, I love the flexibility of the new stuff - ordinary users really can use groups and we have made great strides in the way our public documents are made with SharePoint based links in all the agendas minutes etc. in a way that staff can use and which opens up our data to the public (which we should be doing). The add-ons are great e.g. I taught the staff a bit about planner last week and they were inspired. My issue is that as they have no technical skills to speak of a few things (like consistent metadata) have to be locked down otherwise we will end with inconsistencies and with different solutions to the same problem in different sites, libraries etc. This will rapidly become unsupportable. What I would like to say is that "you always do this" for certain metadata and to arrange centralised management of the "terms". I also feel it hard to advise on how to build the future as SharePoint doesn't entirely seem to know where it is going and there have been a litany of broken promises (e.g. around document sets) which makes me very nervous of saying "do it this way, you won't be painting yourself into a corner". Given that I have worked with MS a lot, had many members of staff embedded in the organisation over many years I feel I know the way the company works and to be honest they can't be trusted on the future (I own a Windows phone -and that underlines the way that MS will just leave customers high and dry without any warning. The list of products that have been pushed, roadmapped, promised then dumped is endless - anyone use Groove?). So it's very hard to be confident that a future you have bought into isn't just promises. Why has it taken 3 years for modern document sets - why is it being delayed again? Why were we told to build hierarchically and now that has all changed?
Like you with respect to managed environments, I feel that SharePoint is currently going another way - but I think these concepts will return e.g. being able to reference data in libraries in your hubsite from the other associated sites strikes me as useful and very likely at some point but it is hard to guess where the MS leviathan might lurch next. - Really - that's very disappointing. .I have been trying to persuade the council to hold off on certain developments whilst waiting for SharePoint to come good - but it's been 3 years (with at least 18 months of that really holding them back). They have appointed a new It supplier who wants to get on with new systems to support new services we will be taking on - I am not sure I can hold the fort for SharePoint against other solutions.
Given the elapsed time and the fact that yet more promised dates have slipped do we have a fundamental problem that might mean that what we get, if we ever get it, will be half baked anyway? Ian out of curiosity how big is your environment, number of users, sites, etc.? For the metadata consistency across site collections I used to use the Content type hub, package term store AKA manage metadata columns into content types and publish these to all site collections. I do not believe the Content type hub is compatible with group sites. I never was a fan of using this, it was not very flexible and a good way to fill your sites up with columns and content types and no simple way to remove items you no longer needed.
Some of the concepts you are talking about I feel like SharePoint is moving away from and becoming more and more dynamic, nimble, collaborative, etc. Like you I often used to stride to drive consistency across every collection, etc. Focused on extensively using managed metadata, required columns, enterprise search centers with extensive usage of refiners, custom search results, etc. Those concepts while still important seem challenging to execute within the modern SP and the focus for us has shifted to providing more user-friendly experiences such as surfacing the document libraries though teams channels, building power apps and embedding in SharePoint sites & Team channels. Mobility for our organization is more important than extensive usage of metadata and the interesting thing is folders are mobile friendly while metadata is not so much. For example, browsing a document library with one level of folders works great on a mobile device through the OneDrive app or offline file sync makes sense when you have a layer of folders for file organization however with only metadata you have a folder of files with no organization. It's kind of bizarre to think we are now building solutions that are using folders when for so many years we did everything possible to avoid them.
We still use metadata extensively when appropriate however mostly with a 3rd party form designer called Infowise, it's much more than a form designer. We will often use it for cascading columns, column validation, associated items or repeating tables. It can provide a lot of added value with driving metadata consistency with it's ability to use logic to default metadata based upon conditions and validation. We also use Infowise to pull data from other LOB systems such as SQL and use this data to pre-populate fields in forms & document libraries. We are building an enterprise document handling solution with Infowise that consumes values from our ERP, Microsoft Dynamics Finance and operations and automatically builds a document set for every project we open in Dynamics. It passes about 12 values and automatically names the document set, sets project managers, emails people, sets security, and populates additional metadata columns for consistency and data findability. With this scenario you can even have a unique document set for each department and each document set has unique and common company content types embedded within them. Since the department is one of the fields that comes from dynamics we use some logic in the Infowise action to automatically create the correct type of document set. It's a very powerful concept and I believe concepts like this can replace trying to create a standardized document library with a specific site column across every site collection. Also, since it's centralized you are not managing 100', or even 1000's s of document libraries. If you prefer to use multiple doc libraries this is also easy to perform within the Infowise actions during document set creation. For example, if department = A use Doc set A and create in document library A. The solution was built with the legacy document sets and we are now waiting for the modern document sets before going live.
Regarding looking data across site collections, are you referring to a lookup column to consume a value from a central list? Have you considered adding these values to the term store than creating a column that points to the correct hierarchy within the term store? You can use this method and have some interesting hierarchies. You can create this as a site column which can be added to every collection and added to any list or library. Previously the content type hub would allow for this to replicate to every collection however this is probably no longer the case with it not working with group sites. That said, as mentioned above any serious document handling for organizational processes such as Project Management, sales, HR, etc. I find using some of the methods mentioned above with a good 3rd party tool to be more manageable than using some of the legacy concepts across 100’s of site collections. Simply put, smaller footprint, less libraries, and investment in a good tool will make it more manageable and open opportunities up in how you facilitate the metadata.
We use Sharegate to quickly copy lists, column, content types, etc. from collection to collection. There are some great tools out there for moving/migrating data including Sharegate and Microsoft has just released a new version of their migration tool.
Road map is now showing Q2
Agreed, some very nice looking stuff. [I will have to revisit the document set issue - I cannot entirely remember all that we were trying to do).
My new "headache" (and it may be misunderstanding by me) is the consistent use of metadata across site collections.
Since I started waiting for modern document sets 3 years ago, the SharePoint world for the "amateur" environment (non-developer/big IT team) has changed out of all recognition with the explosion of site collections via groups (with all the amazing easy to start tools like planner, forms etc, which I love). I get the impression that I am very much steered towards sites and hub site in the modern experience.But I still am worried about consistent use of metadata (not least for user understanding) In the particular tenant where I want to use modern documents sets, meetingdate is an attribute that applies to practically everything that we do (it's local government - law require a meeting for nearly all decisions).
I want to ensure that wherever this is used - even by a user setting up a short-lived group with a quick document library, the name, format etc. is consistent.
I feel what I need is a tenant column (i.e a column definition that applies to every site).
I am slightly hijacking a thread (but this thread does seem to have a high proportion of people who knows stuff).I need (I think)
1) to define metadata columns for all collections (mostly groups) in my tenancy
2) to be able too lookup a lsit across collections - again with have an attribute committee which would be valid in particularly every list our library we would use in any site, group etc. I want to be able to refer back to one master list with these in. (I am sure this must be common requirement - there must be items like office location, business divisions, product codes that would be common to many collections in a client's tenancy
3) A tool to move data from previously hierarchical sites into flatter modern environments or even just take a library from an odl site and moved it to a modern group. I can see issues with metadata definitions but I would have thought moving data, column definitions (which are fulfilled within the source and can be mapped to the same relative locations in the destination) together with an alert for any complex validation etc. that had to removed) would be extremely useful. Is there such as thing?
