I have a list called “Requests” with approx. 40 fields. One field is called “Request Type”
(lookup field to lstRequestTypes) . lstRequestTypes contain 15 different request types. I use a Nintex form to capture the data and it is processed through a Nintex workflow which is running fine.
The business has requested additional fields for the Request form. If the Request Type is “CGA”, collect 8 different fields on 1 to 4 employees. For example
If Request Type = “CGA”, provide values for the following 8 fields for each employee.
From my relational Database days, I would have set this up in its own table joined by request ID. In SharePoint, would I have to set up 32 new fields (4 Employees x 8 fields). The first concern is that these 32 fields would be blank for all of the other Non-CGA Request types. CGA is less than 5% of the requests.
The business said that they usually don’t have more than 4 employees on a request, but if they did, they would ask the user to submit another request. I think it would be good if 1 to X employee items could be created.
How would you set this up and display it on a Nintex form?
Solved! Go to Solution.
Hi Susie Shaffer,
I had a similar request. The way I implemented this is by using a Repeating section, which allows you 1-x Employees, or you can limit the number of rows allowed.
In my case business needed to use the info in views, and as such I created an extra list (List 2) for the details and a workflow that extracted the data from the FormData and created a list item for each row, using the (List 1) ID as relationship. In a page with list view web parts for each list and connecting them you can show the details for the selected parent/master item.
While I do not have the same starting conditions, I have a setup which requires n amount of Repeating Section Rows, all of which get created as an individual List Item elsewhere.
However the way that I have mine setup is almost completely single directional, so none of the XML itself is passed between the main List Form and its children List Items. However I do have a read-only field (That is - something that doesn't show up in the Form / Repeating Section XML) on my main form which can pull real-time information from the Child List Item and into the corresponding Row proper.
Because I didn't like the idea of having children items updating the XML information of the Main Form, I also had to create a system where each Repeating Section Row is given a unique ID during creation (as in New Form, or Add New Row). Using that rowID alongside the ID of the Main Form List Item, the relationship to the Child List Items is already established ahead of time which is a bit different than how most approaches tend to go, such as: Nintex Workflow - Order and Order Items Relationship - Vadim Tabakman.
One thing to include if you're using detail lists: keeping up with updates. I've choosen to delete the detail list items for a parent when the FormData (XML value) changes and create them a newly. You also could try to update the detail list items.....