Hi all,
I am looking into how we can improve the experience of repeating sections and processing the data in workflow. If you have used this scenario, can you please reply with the use case, the data collected, how you process the data and the output?
Appreciate any feedback you can provide.
Cheers,
Euan
thanks for this opportunity.
my ideas/wishes would be:
- store dates in repeating section (internally) always in ISO format, regardless of where dates were captured form (see Nintex Forms 2016 - Wrong date format in XML of repeating section )
use case: if I need to process dates in XML and they are in different formats by clients locales, then if I get date like 2/5/2017 I can not be sure whether it's May the 2nd, or February the 5th. I have no info what locale was the date supplied in. that makes it very difficult to process them in reliable way
- easy conversion of repeating section to HTML table
use case: sending repeating section in formatted table in nofitications
- possibility to add custom attributes to controls in RS that could be then addressable by XPath
use case: let's imagine I have 20 fields in a RS row and I need to check or set their value. currently I need 20 XPath expression to address them by their name.
if I was able to assign them my custom attribute I would be able to address all of them with one single XPath expression.
- add support for XSLT 2.0 and especially XPath functions
(and/or what about to add custom javascript transform function?)
use case: currently used implementation of XSLT 1.0 with (several further restriction) miss plenty of good fetures of XSLT 2.0 (ful standard). plenty of things that could be done simply way (one line of code) in XSLT 2.0 need to be work arounded in XSLT 1.0 in a complicated and complex way, often it involves several workflow actions.
the very same for XPath functions.
example: here I provided some solution that needed to tokenize input string XML Data transform
I had to use some 40 lines of code to achieve that where there already exists dedicated function for that in XSLT 2.0
- easy writing repeating section into list - 1 RS line = 1 item
resp. it would be great if repeating section could be backed by a sharepoint list (apart from XML) as well.
many times it's required to convert RS into sharepoint list (eg if every RS line needs it own approval task). once this is done, it's hard to keep in sync RS content and content in list. if RS were backed by sharepoint list, changes made to list would immediately be seen in RS and vice versa
- possibility to easy duplicate RS' line (in workflow) - line specific XML element/structure without data content
use case: currently if I want to add a line to repeating section in workflow, I have to prepare in advance (in design time) respective XML fragment into a variable. the XML fragment has to follow correct structure of repeating section's row, ie. it has to to contain respective element for every control.
if I later need to change repeating section layout (add/remove controls), structure of the XML fragment changes and I have to remember to update variable in workflow.
if I was able to duplicate RS line's XML structure (without data) some easy way (dedicated action or function) it would always follow actual RS configuration and I wouldn't need to redesign workflow with every change of RS in form.
- merge functionality of update element and add element within Update XML action.
currently, if XPath addresses an element that doesn't exist in XML error is thrown. I would rather liked if element is added.
(use case: there is added new control to RS and workflow is updated accordingly. then workflow is run on old item without respective element in XML. workflow fails to update XML)
In addition to all of the wonderful suggestions already made, I'd like to see a way to use the fields inside of a Repeating Section, as selectable values inside of a Configure Action dialog. By targeting the Repeating Section, the Fields inside of the Row Structure would become available like any other piece of data.
I've created a mock-up to show what I mean exactly. 
Essentially, having some easy way to access the exposed data without having to go through the rigmarole of pre-defining several workflow variables.
It would also be equally helpful to be able to use a Repeating Section form control (from inside of the Workflow Editor) as the controlling iterator (Target Collection) for a Loop Action. 
For Each (Row in Repeating Section) -> Store Row In Variable -> Do Something with Field Inside of Row.
This would save people from having to do the legwork of parsing parsing the XML, gathering the Items into a collection that could be iterated on, making an iterator storage variable, creating a series of collections for each field, and then trying to keep up with iterating over those collection variables in a tangled mess.
The easier it is to parse the data, the happier I'll be!
Thank you for your time and work on this matter!
I'd love a way to define an attachment per repeating section.
Write your expense report item, attach the receipt... add new repeating section, write expense report item, attach receipt... which means I'd also like a way to define attachment name based on the repeating section item's particular metadata.
We use a form that builds an invoice document. The repeating section has controls to identify the line item from a drop down, some fields are auto filled, but quantity and other amount information is added by the user per item. In the workflow, we XPATH parse to figure out all the various end user inputs and then move to collections, then eventually we create a list item in a second list per item in the repeating section. Then another workflow picks those up and moves information into an external system for payment processing.
The repeating section is great. It is always just a bit of a mission to get to the point where you actually start getting data from a repeating section. I also use the QueryXML action to get the data and maybe I'm missing something obvious but I generally have to play around with the run now and log in History actions to get the right fields.
I think it would be great if a separate action could be added (based on the query XML) that will read the structure of the repeating section as soon as you point it to a repeating section and allow you to select the element or field that you wish to extract instead of having to type it in as free text.
Second thing would be to display the data better in the SharePoint list. Isn't there a way of displaying the data as ;-delimited rather than displaying blank in the SharePoint list?
Third (wish list item) thing would be to have a field that auto numbers inside a repeating section as soon as you add the next row. If you have multiple repeating sections on a screen each of them should be able to start at 1 and sequentially increase.
Let me know if you want to expand on any of these?
Kind Regards
I don't have much more to add on to what's already been mentioned, but I'll explain a couple of our use cases.
Firstly, we are using a Nintex Form to capture Meeting Minutes, and at the end of it there are "Action Items" which is currently a repeating section, each of which has an "Item Name," an "Assigned To," and a "Due Date." The Assigned to needed to be able to have multiple people in it and we wanted to send an email to them to let them know about their task. That took quite a bit of RegEx and XML manipulation to achieve.
We also had a use case for a "monthly report" for a facilities manager where he could have a large header for a project and then list out his accomplishments and remaining tasks underneath it.
on Apr 10, 2017
Hi,
Several times I've had the need to store in a form several "sets" of data (e.g. product name, number of items, color..) so I've used a repeating section.
After data entry, the workflow may read the repeating section using the QueryXML action in order to extract some info and use them in the workflow (maybe with product name I can query a Price List and multiply the value for the number required in order to get the total cost)
After that I may update again (using UpdateXML) the form to store that value in it, so it's available also in the form.
Suggestions:
- Having the capability to automatically decode a repeating section when querying the form (the actual result of the query is an encoded xml and we have to do an additional action in order to decode it)
- Having the capability to query directly for fields inside a repeating section (and store values in a collection variable)