Hallo all,

Whats the best practice to publish a form to be connected to a Content Type, declared  on Content Type Hub?

Somehow this whole admin-approved stuff applies only to browser-enabled forms, but we have now concluded it a feature too buggy and sensitive by Microsoft to be used in productive environment, at least for a complex form like mine. So we go back to Filler-only-Form. To my surprise I run into other difficulties...

1. I configure the content type on the hub

2. I publish the form to that content type, the xsn-file lies in a document library "FormServerTemplates" on the hub

3. when I go into advanced setting of that content type it refers to "/FormServerTemplates/mytemplate.xsn" (relatvie path, not absolute!)

4. then I republish the content type and run the subscriber job

5. then the funny stuff begins. In my  target library, that I have this CT set to be used, in advanced settings I can see, it also refers to that "same" relative path, but ofo course, there isn't any form template, so I cannot create a new form.

6. so I go back to the Hub Content Type and upload the template into the CT itself from, using the file in that document library I mentioned in 2.

7. republish and run subscriber job again

8. back in my target library it now says "mytemplate.xsn" in advanced settings.

9. I can successfully create a document and save it back to that form library and cannot see any errors.

10. If I want to relink my form using the library's repair.aspx-View it would relink my form not to the current CT's setting, but to an XSN-File in that library. Instead it should point to ".../libraryname/Forms/CTname/myTemplate.xsn"

Why do I relink? Well Typically we go productive with real data, but with a "close to final, but beta-form". When I actually go final, I would relink the beta-forms, since they shall live on.

I have not found any other way to use the content type mechanism with InfoPath-Forms. I don't understand why I cannot use the solution way, as it is practiced with browser-enabled admin approved forms. In the end I need to use my forms in various different site collections, how can achieve this, other than what I described?

I appreciate any thoughts on this very much.

joanfuture:

Whats the best practice to publish a form to be connected to a Content Type, declared  on Content Type Hub?

You publish an Infopath form template as content type to its own sharepoint form library (with a name of your choice) as a content type

In order to add content type to a Sharepoint (form or document) library

• Navigate to a SharePoint Form/Document Library -> Settings -> Form/Document Library Settings -> Advanced Settings
• Mark Yes to "Allow management of content types?" > OK

Back in the Form/Document Library Settings > select Add from existing site content typesunder Content Types section

For example,  I created 2 sharepoint form (could be document) libraries in 2 subsites:

• TestSharedCT1 form library in Web3 subsite
  _https://gennadyvanin.sharepoint.com/Web3/TestSharedCT1
  
  
  
• FormLibInAnotherSite form library in Web2 subsite
  _https://gennadyvanin.sharepoint.com/Web2/FormLibInAnotherSite
  
  
  

having added to them the same content type published as content type SharingIPContentTypeBetweebSubsitesCT from an XSN Infopath form template SharingIPContentTypeBetweenSubsitesTemplate.xsn

The location of XSN Infopath form is irrelevant, but in my case it was calledSharingIPContentTypeBetweenSubsitesTemplate and stored in a form librarySharingIPContentTypeFormLib of root site _https://gennadyvanin.sharepoint.com/

• _https://gennadyvanin.sharepoint.com/SharingIPContentTypeFormLib/SharingIPContentTypeBetweenSubsitesTemplate.xsn

Note, that the the last 2 sharepoint form (could have been document) libraries  where I used a content type do not have any data connections or templates published on them!

joanfuture:

Somehow this whole admin-approved stuff applies only to browser-enabled forms

This is generally incorrect statement and I do not know to what you are referring to

 While administrator approval of  forms appear at some circumstances but they are most probably appear when one publishes rather a filler than a web browser form

And, even this, can be avoided if to convert the culprit (causing the necessity of Full Trust + signing with a digital certificate) data connections to UDCX connection files stored in a sharepoint data connection library on the same site collection (so, avoiding the necessity of Full Trust + signing with a digital certificate and/or adminstrator approved forms) 

joanfuture:

2. I publish the form to that content type, the xsn-file lies in a document library "FormServerTemplates" on the hub

It is impossible to publish a template to a sharepoint document library, only to a sharepoint form library

Sorry, I stopped reading further

thank you Gennady,

I believe, you are describing correctly the procedure to use one form template with one Content Type in one (1) site collection, are you not? But now I want to have that content type in the other hundred site collections (not subsites), I need to scale it, without having more effort of course.

I know of two mechanisms to distribute content types:

1. using the content type hub (which we use successfully with word-Templates)
1. I subscribe to the hub and get the CT with template
2. and in case of InfoPath the solution-based approach
1. I activate the feature on the site collection of my wish, however this seems to work only with browser-enabled forms. Well, I don't want it to be browser-enabled :-) I should be preferred with my retro-client application approach.

Hope to make my problem more clear.

Michael

with the second (content type hub-based) approach, i have now further issues:

well, it mostly comes down to the fact, that I cannot set an absolute path for the Content Type on the Hub.

Because i cannot do that (to my knowledge)

1. Relinks via the standard method fail (I already mentioned that above)
2. Muhimbi Converter needs to have Read-Access to the xsn-File, which I have to solve by giving it explicitly. I can understand that this must be this way, but it just puts more overhead on all administrators. i guess I will make the account SiteCollection Administrator, because a subsite administrator may accidently take the rights away, because it is "weird" account.
3. I don't quite know, where to put my Nintex-Workflow, that will start, when I save my form in a "published" status. The Workflow is to convert the InfoPath-form to PDF and sends it to the meeting's attendees. Must I put this workflow on the hub or do Ihave to configure/import/activate it on each site? What if I change it, then I must do that in all site collections?

I think thats the errors/misbehaviour so far. Of course i will approach Nintex concerning no 3, but I am sure, other people have nintex and qRules in place. I will update this thread, when i have a new status.

The questions remains, how I can (comfortly) distribute a filler form to different site collections.