Skip to main content

Although most of our Nintex Forms are used solely in the office, we have always defaulted to Responsive Form designer, as it is a more streamlined workflow: limited styling/sizing options, auto-alignment, etc..

 

As our client’s needs have evolved, we find there are several forms we would like to migrate to the classic designer in order to pick up some form controls that are beneficial (List View, etc.)

 

I understand there is no conversion tool, but am hoping someone could give us some best practices from a practical experience.  The current responsive form is fairly robust (many different columns, controls, rules, etc.), and is actively used.

 

Some early thoughts we have:

 

Scenario #1: “The long weekend”

  • Export the form to local storage
  • Delete the form and rebuild using Classic Designer
  • If we run into issues that prevent completion over the weekend, revert to Responsive and import locally stored copy

 

Scenario #2: “Parallel list”

  • Create a list template of current list
  • Create clone list from template
  • Develop form on cloned list using Classic Designer
  • Go to original list
  • Export Responsive form to local storage
  • Delete existing form and start a form using Classic Designer
  • Import form from cloned list
  • If we run into issues, revert to Responsive and import locally stored copy

 

Anyone out there develop a “best practice” for this type of effort?  Any script to allow us to convert to Classic by editing the exported XML of the Responsive form?

 

Thanks!

Just knowing how different Classic Forms is to Responsive, I would opt for that second approach. Depending on the size and scope of the form in question, it could easily take more than a weekend (especially if you're getting feedback from someone in the company who has to use the new re-design and might not be used to the stark visual change). 



 



Unfortunately I do not know of any tools to make this easier. 

Thanks so much for the feedback!

@bgarvey Thanks for your post. I was curios to know more about your use case and intended outcome on the Form for users to see if we can look at providing a solution in the next generation technology, New Responsive Form.

I have a SP2019 site where one list has a few thousand entries. Lots of rules used as process guardrails, lots of fields where we use buttons at the top of the form and panels to act as pagination. The form also acts as a launching point to load documents into various doc libraries, bringing in metadata via URL parameters to the receiving form. For speed to market, we used responsive designer, even though no field users or iOS users are involved.



Over the time, the process has been revamped so many times, that many rules have been come unnecessary, or fields removed that were in rules, etc.. After documenting the process and gathering requirements, we decided to create a new form v 2.0, and leverage classic designer to pick up things like:





  • embedding filter list views of related doc libraries


  • JS buttons


  • pagination


  • minor jQuery actions to set field values on the fly


  • other minor items that are classic only






Currently we have copied the site down to QA, will confirm all matching guids etc, and start with a fresh form there. Our workflows are also a mess, with about 15 firing on every change. We intend to combine as much as reasonable, keeping individual functions as Manual only for cases where a wf gets hung. We would love to use more conditional wf's, but they seem to bog the form down on Save.



Unfortunately, we are stuck on prem for now, as our work has federal compliance regulations wrapped up in the data portion. Thanks for the interest, let me know if you have any other questions!

Thank you @bgarvey , appreciate the details and understand having to stay on-prem due to federal compliance. Would you be able to possibly provide any screenshots of the following with confidential data crossed out:







  1. Lots of fields where we use buttons at the top of the form (are these also referred to as "JS buttons"?)


  2. Panels to act as pagination


  3. The form also acts as a launching point to load documents into various doc libraries, bringing in metadata via URL parameters to the receiving form. (is this the same as "embedding filter list views of related doc libraries")


  4. Minor jQuery actions to set field values on the fly




And please do not feel obligated to take any further action, as I am only trying to learn more about customer use cases, see the form elements and intended outcomes. Thank you



@bgarvey And the learning is also intended for improvements in our next generation forms platform to accommodate your use cases.

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings