I am creating a form that will be accessed via the Nintex app. I have a form with 452 controls which are required to capture data all the data for a mechanics service sheet, excluding attachment controls, rules and displayed images. I got around the SharePoint column limitation by not outputting 245 fields to the SharePoint list. These I would access via xml. It didn't then click that there would be a form limitation as far as controls go. Because of course the 452 pieces of data still needed to be captured.
The most important requirement is that all the data needs to be output to a single email so that a supervisor can see the entire service in one go and approve/reject/update the form from a PC as need be. There will be a workflow behind the form where two levels of approval are required and both of these levels will have the ability to update the web form as need be.
I've spent a couple of days looking at Content Types, in the hope that this might be a solution to reducing controls on the form. I believe there is a Content Type ID that can be used to connect everything?
I could break the form up, but the separate forms need to be linked somehow for the email output, and I can't see how to do that.
Any suggestions would be appreciated. Also, how to access the data in a Content Type from a workflow.
Solved! Go to Solution.
The first thing would be to really take a look at whether that "mechanic service sheet" as it currently is, should be replicated into a form and is it necessary for the users to see all that via email? When transferring from one technology type to another we often try to keep things as they were which breaks how technology should enhance the process. While email is great, it may be cheaper easier and better to leave it on paper if all they are doing is moving a bunch of data around.
Moving it to SharePoint should allow them to see the information, access it via links, etc, and do approvals via the workflow. If you think a 250 control form is hard, imagine reading all that in formatted email on a phone. Yikes...I wouldn't want to be the one whose job is on the line because I missed a critical piece of data skimming over it in email.
Having said that, you may in fact need all of those fields; the next question would be to determine, when in the process do you need them and if you can split out which ones are needed first, second and third. 250 controls on a form would be a nightmare to complete and even on a 10in iPad, still would need a save and update button at minimal.
Linking data is a great option to consider and it could be done from a standpoint similar to this:
Just depends on the form and what all you need to collect.
Thanks Eric. Unfortunately I argued every point I could think of to not output all the data to one email. I wanted to break the form up but they insisted on receiving one email containing all the data.
I'd be happy to have more than one form, but how do i link the data between forms for the output? I'd need a shared unique value and I'm not sure how to set that up.
Joanne, can you confirm what versions of forms and SharePoint you're using.
Using on-prem Nintex Forms 2013 in SharePoin 2013, I had a lot smaller requirement (about 30 Qs) that I managed OK - by outputting the values into an HTML table inside notification/approval emails - with a link to the original form (for viewing/changes) and a link to an approval form (for approval notifications).
On the form input screen, I have check-boxes. This data is not shown on approval forms just this form or emails.
I set √ as a variable called CheckMark (other characters did not work so well in HTML). For each form check box, I created a workflow variable.
Then in a large action set, I have a series of run-if actions for all the check boxes.
For example question EQ01 if true, EQ01checkmark=CheckMark...and this goes right through all the variables in the checklist.
I then have a simple, but long HTML tables undier your text in the task notification emails. And it does squash-up reflexively on iPhone screens - making Lazy Approval an option for mobile managers...
So my question here is are you trying to control the input or the output. The output can be done but the workflow would be ugly. You could push to multiple list, then use query list to pull the data back and use build strings to compile all that back for a single email.
With our new doc gen action, you could do the same thing, simplify the output and shoot them a nice document to review and approve. I know its not what you asked, but I'm not sure their requirement is any better than that either, LOL.... Sorry I can't help much.
Keeping in mind this is an iPad App form, the output requirement is what is causing the issue. And I'm used to ugly workflows, given the diverse requirements that I receive I always use build strings to output data to emails. The problem with this one is that because of the SharePoint max column limitation and the form max control limitation, I either need multiple forms connected by unique ID, or my last resort is content types output to separate items but still connected by unique ID.
I would really like to know if there is a Content Type ID that links the multiple Content Type items to the original form item. I don't want to update the original form item with the Content Type data, as there will be an issue with the max column limitation.
Is the new doc gen action available for Nintex Workflow 2010 (Version: 184.108.40.206). I'm thinking not. What is it called? Sounds very interesting.
I've come to the conclusion that content types won't work for app forms as they can't be edited from the app. So depending on what the new doc gen action is and how it works (if at all) with the app, I think my only solution is to break the form up and produce multiple email outputs for the user.
You're correct the doc gen action was created for O365 only first. There are some other options and I'll explore some to see if this is an applicable case for it.
As for your connecting content. If you use lookup columns to connect the different list, you should be able to fill out the form, push data to the separate list, then pull that data back together for a single email using the build string to compile that data from the different list as necessary.
The output requirement is indeed the big issue here, and I'd be willing to help them do something better and support you on the initiative if that could help them do something better. To that end, you can tell your PM or whoever is driving this project that I'm willing to put my services on the line for this fact. "If between the two of us, we cant't give them a better solution that increases productivity and efficiency while still giving them information they need to act and make decisions, than I'll give up to 40 hours of an effort for it for free. WOW!!! I haven't made a case like that in a while and the last time I did it, the solution surpassed their expectations and its still working :-). To show how serious I am, I'll announce it on the hangout Dec. 16 to up the stakes :-).
Thanks Eric. The form has gone on hold, mainly I think because of the length of time it took to address all the issues that arose. Your simple solution of linking lists via a lookup field is a great solution to my multi form/list issue. No idea why I didn't think of that myself.