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.

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.

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.

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

Who's David?

BTW, I have to apologise when I earlier said that customisations to incorporated site columns at the list level were preserved. I just did a couple of quick tests myself and can confirm that the customisations are indeed lost when you push down an update from the site column level. In fact, it even says so right on the page!

I don't know what I was thinking when I was so convinced that customisations were preserved. Perhaps I had removed a content type, but the instance of the site column remained at the list level and was hence no longer inheriting changes?

Anyway, in this regard, I would say that Nintex Content Type forms behave in the same way as site columns do, however, there's no option to "Update all the forms based on this form?" as it just defaults to yes and customisations are overwritten.

Thanks for the suggestion to raise the user voice improvement, I'll do that shortly!

I found an existing suggestion that was in line with mine, so I voted for that as well as commented on having the option to propagate updates down to child forms. Reference: Work away the differences between forms on content type and list level – Customer Feedback for Nintex