Site Columns Best Practices?

  • 15 November 2017
  • 2 replies
  • 4 views
M
Badge +7

For reusability / consistency, I often find myself creating Site Columns, then adding these to a Content Type. This Content Type is then used in my List(s) with, typically, a Nintex form and workflow attached. So my question is in regards to the usage of Site Columns and whether it's best practice to reuse or create?

For example, let's say I've created a Content Type with a Nintex form that requires a Delivery Address field. In SP2016 there's an Address site column (Multiple lines of text) available in the Core Contact and Calendar Columns group. I could either add this existing site column into my new Content Type, or, create my own "Delivery Address" site column and add that to my Content Type.

Reusing the site column is appealing in the sense that it scales better, and reduces the amount of duplication. If I had 100 content types with forms each requiring a delivery address field, it's probably more efficient to have the one Address site column reused 100 times, rather than 100 site columns of essentially the same thing. However, creating a new site column is appealing in the sense that it's self-contained, that is, the Content Type "owns" all of its site columns. This lends itself better towards portability.

If anyone has any thoughts, real life use cases, or insights into this, I would appreciate hearing them!

2 replies

G
Badge +2

For me it does somewhat depend on the case as I think there is no right or wrong answer.

Things I take into account are:

Is the column only to be used in one site collection for a one-off purpose, or multiple collections

Is the column to be searchable / retrievable / refinable by content search, or other aggregation

How are you creating / deploying the columns (e.g. browser, provisioning methods such as PnP, Content Type Hub)

Personally, if there is an existing column such as Address that suits the content type purpose, I tend to use that rather than creating a new one. If I anticipate the field needs to be changed in any way (e.g. changing its settings such as name, form visibility) I tend to create a new one. If you are creating 100 content types in the same site collection, then you can't create 100 columns with the same name in the browser anyway?

In your case above I'd lean towards using the built in column. The thought of having 100 columns that are all essentially the same seems like it's not necessary.

M
Badge +7

Some good points raised there, Gary, and I suppose the real answer is "it depends". In my particular case, I'm not really sure what or how the columns or content types may evolve over time, and in that regard I'm trying to consider ways to "future proof" them as much as possible, but without overdoing it. And to address some specific points:

If you are creating 100 content types in the same site collection, then you can't create 100 columns with the same name in the browser anyway?

That is correct, so you would need to come up with some kind of naming convention in order to manage things. One thing I like to do is prefix the column name with the initials/abbreviated Content Type name. So, in my fictitious example of 100 Address fields, they'd be internally named as aaAddress, bbAddress, ccAddress, etc, then renamed into something more readable later.

 

In your case above I'd lean towards using the built in column. The thought of having 100 columns that are all essentially the same seems like it's not necessary.

Agreed, but one thing to be aware of is that that you cannot include the same Site Column more than once in a Content Type. For example, if you're using the core "Address" Site Column in a Content Type but also require additional Address fields, then you're forced to essentially create new ones, or find alternates if they exist. This, to me, starts to get messy and I would start leaning toward the creation of all the Site Columns just for consistency.

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings