Creating new column types in modern SharePoint lists and libraries

While this kind of functionality is great for the end user  I have to agree with many of the comments above.

365 and SP is an enterprise platform but many of the the functions being rolled lack enterprise thought.

We made massive in-roads in the past 10 years in removing islands of data with SP...it seems we are creating islands of app data (teams, groups, planner, sway etc)

Enterprise content management is based upon a solid information architecture.....from an sharePoint perspective this starts with properly managemed columns and not throw-together taxonomy.

As I said, great for the end user BUT retro fitting proper info architecture down the line will be a nightmare

I think at a minimum, the option to control access to this function per location is necessary. We also use views, and not all views show all columns. What we've seen happening is that users want a certain field that already exists, but they think, "hmm, I want that 'date' column to show up," so they add a new Date column rather than switch the view or add the existing column (as Pieter suggests--great idea!).

I totally agree with Stephen--we need to empower users. But that doesn't mean all users are experts at IG in all situations. Sometimes data structures are created by teams through great discovery exercises, and all will benefit if the plan is followed by the whole team. One eager, well-meaning, but unfamiliar user can quickly ruin that. Control can empower users, too.

This new functionality is great is some scenarios. But we need at least the option to control when control is necessary. 

Yes, with empowering those that know nothing about data structures normalization Etc comes difficulty in governance.

In the new world we have to view those as prototypes for rework (a step in agile development)

what happens when the every day user contacts the technical person complaining about

- performance?

- Things not working as expected... 

- search not really working

- more complicated scenarios need to be addressed

quite often we have to tell those users. Oops it is too late now.

putting thought in you data infrastructure quite often makes sense.

of course we do want user to be able to do things that they want... but should we not guide them in the right technical direction.

maybe include in the add field dialog an option to select an existing field?

To me, what you guys have described in your comments is the old way SharePoint on-premise worked. Problem is in this new world of Web Apps, cloud, ditigal transformation, and Saas solutions, anyone of your team can get an app off the self, configure it to meet their purposes and be running very quickly.

I think what Microsoft is doing here is great, it makes solutions flexible and dynamic, it enables digital transformation at every level of an organisation. By using the old method users had to come to an expert/admin to set up Content types, create a new site column. All the control sat with these people, this is not good for organisations in this new world. Everyone needs to be enabled to get on and do the job, work as they want to be able to work.

I've been an SharePoint Admin, developer and I am as technical as most, but what I see is that the only people that seem to struggle with this, are the techies, admins and people that want to control how solutions are built. This unfortunately won't cut it ... we must empower, we must enable, we must trust that people will use the technology in a way that will benefit thier organisations. 

Agree with both of you...it's like the best practices around metadata are not important anymore...and I don't like this

Hi Pieter Veenstra - I thought the same thing.   I generally encourage the use and creation of site columns vs. list columns.  I agree with the reason you suggested:

• Ability to add same column to multiple lists\libs.
• Site columns are the type of columns used in Content Types.

I would add search to that.  It is my understanding that Site Columns (with values) are 'promoted' to managed properties.

That said - I would welcome a deeper discussion.  One of the challenges is that many quick reference cards, 'how-to' documents, video tutorials, provide examples of users creating list columns. 

Is this really the right place to create columns?

Should columns not be created at the site collection level rather than the list level. This is where users in the past have done a lot of damage to their SharePoint solutions.

Isn't there a reason that the PnP provisioning team didn't really want to support list columns? Simply because it is better practise to create the columns at the high level of the site collection so that you only need to create one column rather than the same column multiple times across the lists.

Additonally, isn't it recommended to create content types and then add the custom columns to the content types?