cancel
Showing results for 
Search instead for 
Did you mean: 
michaela
Nintex Newbie

Content Type Forms vs List Forms

I'm trying to understand the relationship between forms created for a Content Type, and how that form manifests itself on a List that uses that Content Type.

In my specific example, on the Content Type form I wanted to display this calculated control:

Published on: {ItemProperty:Created}

However, when authoring the Content Type form, it has no notion of Item Properties -- not even the built-in ones (Created, Created by, etc) -- so this is not possible. I then thought if I edit the form on the List where it's being used, I can then access the Item Properties and include this calculated control. And what do you know? It worked!

In my mind, I assumed that I had now created an instance (or customised version) of the Content Type form in my list. But when I went and updated the Content Type form again, I had lost the customisation to the form on the List.

So what's happening here? If forms for Content Types cannot be customised, why allow the user to even modify it at the list level? Or why can't built-in Item Properties be accessed in the Content Type form editor?

Tags (1)
0 Kudos
Reply
12 Replies
jpmhuls
Nintex Newbie

Re: Content Type Forms vs List Forms

Hi ‌,

One example where you would need this is in Document Set libraries (or lists/libraries where you use multiple content types). Your document set library can consists of multiple content types and it is here that you can customize each content type's (list) form with Nintex Forms Designer.

NB: I'm currently working with Nintex Forms 2013 on a SP2013 on-prem environment and there it does not allow me to customize the form of a content type definition with Nintex Forms Designer; so only in lists/libraries.

Hopefully this answers your question.

0 Kudos
Reply
michaela
Nintex Newbie

Re: Content Type Forms vs List Forms

Hi Jean-Pierre Huls‌,

I'm not sure if you understood my question, or if I explained it clearly. What you described I'm already very familiar with, which is creating different Nintex forms for different content types at the List level.

What I'm referring to is at the Site Settings > Site Content Type level. Let's say you create a Site Content Type called Apple, and on the settings page for the content type Apple there's the ability to create a Nintex form so you go ahead and do that.

Now you go off to your subsite and create a list, and on that list you enable the management of content types and add the Apple content type you created previously. Additionally, the form you previously created for this content type is also now available in your list, and in fact, it will be available in any list that includes this content type.

The problem I'm describing is related to what happens when editing this form. Specifically, depending on where you edit the form can result in unwanted side effects. If you edit at the list level, you'll custom the form for that list alone. But if you edit at the site level, you'll overwrite the version at the list level, potentially losing any customisations you previously made at the list level. Which leads to me to my question of why allow the edits at the list level, if edits at the site level can (and will) overwrite them?

An analogy would be if you consider Site Columns used in a specific list. If you don't change the definition of that site column, then edits to that column (at the site level) will propagate to your list. But, if you modify the site column definition at the list level, it ceases to inherit, or be linked to, the Site Column and so subsequent changes at the site level will not impact your list's customisations. I thought Nintex Content Type forms (created at the site level) would behave in a similar way, but my experience has shown otherwise.

Hopefully that describes the problem a little more clearer.

0 Kudos
Reply
jpmhuls
Nintex Newbie

Re: Content Type Forms vs List Forms

Ah ok. Would that be SharePoint on-prem or O365? As mentioned, the SP2013 on-prem environment I'm currently working on does allow for a content type to have the form changed with the Nintex Form Designer. When doing so it returns an error, which I think is due to a wrong configuration. So at this moment I can't reproduce your issue.

Btw: the described behavior sounds consistent with changing a site column with list inheritance activated: if you change it in the list, then change the site column the latter will overwrite the column change in the list..... Is there an inheritance setting when editing the Nintex Form in the content type?

0 Kudos
Reply
michaela
Nintex Newbie

Re: Content Type Forms vs List Forms

Oops, I forgot to mention I'm using Nintex Forms 2016 with SP2016 on-prem. There are no inheritance settings for Content Type Nintex forms that I know of or can find.

Also, I'm a little surprised to hear you mention a "list inheritance" feature with site columns? Where is that? Because the experience I've had has been the opposite -- that is, if you edit the site column at the list level, you break the (default) inheritance from the site column.

0 Kudos
Reply
Highlighted
jpmhuls
Nintex Newbie

Re: Content Type Forms vs List Forms

At the bottom of the site column you have "Update all list columns based on this site column" ("Specify whether all lists using this site column should be updated with the settings on this page. This operation can take a long time, and any customizations made to child list columns will be lost."). So, yes, it's not exactly inheritance, but it comes very close: And my educated guess (I haven't been able to work with SP2016 on-prem yet) would be that this still is in place in SP2016 on-prem.

0 Kudos
Reply
michaela
Nintex Newbie

Re: Content Type Forms vs List Forms

Yeah, that's not inheritance  

Once again, even if you try to propagate a change from the Site Column level down to all lists that use the column, if any of the lists actually customised the column then they'll cease to inherit future changes.

0 Kudos
Reply
jpmhuls
Nintex Newbie

Re: Content Type Forms vs List Forms

Hi Michael,

I agree, as long as the "Update all list columns based on this site column" box is not checked. If it is, it will overwrite the column in the list.... I've just tested It with the list update setting active and:

  • column name changes are overwritten when name changed on site column level
  • and the same is true for values e.g. choices. Added choices to the site column in the list are also overwritten when changing them (or the column name) in the site column settings (Site Settings level).

At least in the current SP2013 environment I'm working on.

0 Kudos
Reply
michaela
Nintex Newbie

Re: Content Type Forms vs List Forms

Jean-Pierre, just to clarify, is the site column in your list added directly to the list itself or via a content type?

0 Kudos
Reply
jpmhuls
Nintex Newbie

Re: Content Type Forms vs List Forms

Hi Michael,

I've tested both scenarios..... and in both cases, with "Update lists using this site column" checked, changing one the site column's settings overwrites any changes made to the list column that's based on the site column. Either as part of a content type or when added as site column directly to the list. As you clearly have witnessed/experienced a different behaviour, I'm a bit confused why we both see this difference.

Anyway, and meanshile I tested the content type Nintex Form on a different SP2013 farm, and there it works as you describe. Maybe you could raise a Nintex User Voice improvement to include a "Update this Nintex Form in lists/libraries using this content type" setting. If not checked, then only newly created lists where the ct is added should get the updated ct Nintex Form and existing ones with customizations remain unchanged. Unless the checkbox is ticked.

Reply