Skip navigation
All Places > Getting Started > Blog > 2017 > October

This post intends to show printing correctly filled out Nintex forms without validation error summary messages and highlighted fields. Nintex form validation warnings were still visible when I printed the successfully validated form that pictured below.



I have added the lines of JQuery codes that before the window.print() call listed below.




Finally, I have printed the correctly submitted form without any validation warning on the printout that shown below.



Nintex Forms Edit Mode

Posted by blalocb Employee Oct 25, 2017



Can I use “Is Edit Mode” to lock a form during editing?


For example – someone submits the form and the workflow sends it to a group for review – group is Reviewer A, Reviewer B, Reviewer C. If Reviewer A opens the form can it be locked so Reviewers B and C cannot not edit it simultaneously.




Because there is no Check In / Check Out functionality on SharePoint lists, this one would need to get a bit creative.


There are a couple of ways you can go about it, but this is the way I would set it up:


  1. Create two additional columns in the list “Check Out” (with option for Checked-In or Checked-Out) and “Checked Out To” (people or group)
  2. Create a calculated value control on the form and connect it to the “Checked Out To” control, and set the formula to “Current User”
  3. Add a save and continue button (can be renamed check in /check out)
  4. Create a Disable rule and apply it to the Save and Continue button and the “Check Out” control. The formula will be targeting If the control is ‘Checked Out’ and the Current User is not equal to the ‘Checked Out To’ item property (this one may take some tweaking if the postback doesn’t refresh the item property in the form designer).
  5. They can throw the rest of the controls in a panel and put a rule on there that disables the controls if the status is Checked out and the current user is not equal to the checked out user.


This is going to be the conceptual way to throw it together, from there are a few different ways they can stylize it to make it fit their needs (IE not using a choice control and just doing JavaScript for the button). 

As a systems integrator in the Microsoft SharePoint space I often get asked comparative analysis questions on forms and workflow products. Due to the announced end of life of InfoPath, one of the more common comparisons I see is on Nintex Workflow and Forms compared to PowerApps and Flow. Since I’ve had a number of meetings on this topic with multiple clients, as well as discussions with folks at Nintex, I thought I’d share what I’ve learned. 

Why Compare These Products

It may seem obvious but I always find it important to be very clear about our argument for comparison. The primary reason I hear from client is:
“We got InfoPath for free and now we’re going to get PowerApps and Flow free with our E3 licenses, why would we pay for Nintex?”
No surprises here, cost is the primary driver. 

My comparison below will cover a lot of feature differences as to why you would pay for Nintex, and what you get for that extra cost. Some of the elements, like ease of use and learning curve are touched on and I've seen executives use these as the driving financial factor as to why to invest in Nintex. Making the business case for the cost of Nintex is a case by case thing that is typically better done on the phone. See the end of this article for my contact information and I'm happy to discuss it with you.

Before we dive into our comparison I think it’s worth mentioning a few things:

My Opinion

Most of the information below is based on facts, however I do also offer my opinion on these products. You may be wondering, why should I care about Owen’s opinion? Well, you certainly don’t have to    but to give you some background, I’ve been developing solutions for Fortune 500 companies for over 7 years and in that time, I have designed and built over 100 complex workflow solutions in Nintex, SharePoint Designer, and Flow. I also have extensive experience working with IBM BPM, K2 and other lesser known workflow tools. I’m a big fan of process automation and after many years working intimately with these products I like to think I’m a bit of an expert. In the end, my opinions are mine alone so it’s important for you to form yours as well.

A Brief History of Microsoft Forms and Workflow

In 2014 Microsoft announced the discontinuance of InfoPath. This was immediately followed with fear and anxiety from many enterprise customers who had, for over a decade, been using the tool to create simple to extremely complex forms and applications. Microsoft’s announcement did state support for the client application until 2026 (originally 2023), however the biggest fears arose around the uncertainty of InfoPath Forms Services (the engine in SharePoint that would serve up InfoPath forms as web based forms inside of a SharePoint site, list or library) and how long that would be supported. To this date, Microsoft has only said that it would be fully supported in Office 365 “until further notice”. That being said, I’ve already run into cases where it is no longer fully functional.
In 2015 at the Microsoft Ignite conference, Microsoft announced the SharePoint Designer’s (SPD) latest release (2013) was it’s last. They did state that SPD 2013 would work when connecting to 2016 (which it does), but that they wouldn’t be releasing a new version. In reading between the lines, this was the first indication of the future, yet to be announced, death of SharePoint Workflow.
In April of 2016 Microsoft officially released PowerApps and Flow. They discussed a roadmap that would position PowerApps as their recommended replacement for the space InfoPath filled, an intuitive forms designer, and Flow as the future replacement for SharePoint Workflow. Both products have unique pricing models (Flow, PowerApps) but are included in Enterprise licensing for Office365.
PowerApps and Flow are almost 1.5 years from their GA release date and they’ve come quite far in that time. New features are being released each quarter and there is an obvious dedication from Microsoft to make them a powerful addition to the suite of tools in the Office365 and Azure space.

A Brief History of Nintex

Nintex has provided a workflow solution for SharePoint since its inception in 2006. In 2012 Nintex released their first Forms product for SharePoint. In 2016 they released an independent workflow platform called Nintex Workflow Cloud (NWC), making it their first non-SharePoint related product. They also have a business intelligence tool to analyze your workflows called Hawkeye, a document generation tool through their acquisition of Drawloop in 2015 and most recently they announced a new workflow platform for Box.
In the SharePoint space Nintex has positioned itself as a leading workflow and forms add on and has focused on the ease of use and additional functionality of their products over what Microsoft offers.

Nintex Forms vs PowerApps

Let’s start with comparing the forms tools. Both are powerful ways to create forms, however there are some significant differences that should lead you to choose over the other based on your need:

Learning Curve

PowerApps is being positioned by Microsoft as a tool for business users, however in my experience it has a bit higher of a learning curve than may be marketed. Though the tool allows you to write Excel type functions for your business logic the concepts of data objects, properties and accessing those properties can quickly confuse a business user who doesn’t have at least some light coding exposure. For me this places PowerApps primarily as a IT Pro/Power User tool.
Nintex’s Responsive Form design experience is much easier to learn and users can quickly create a responsive form without worrying too much about aesthetic layout or pixels. When dealing with business rules Nintex does require users to use JavaScript syntax to write Boolean logic, however they assist with buttons for logic operators and a future release will provide a much better, non-development rules builder (that already exists in NWC). Nintex’s Classic Form designer is also pretty easy to use but form builders need to handle layout in a way that is similar to PowerApps. This experience does still have a leg up on PowerApps as the rules builder is still more intuitive in my opinion.

Who Owns the Form

With PowerApps, all forms are owned by a single user, typically the designer. The current advice from Microsoft is that when deploying a form to production you would use a production service account (yes it would require a license) that would own all forms in production.
Nintex’s Forms are owned by the List, Library or Workflow. Users have the rights to create or edit forms, but any other user who has rights can go in and update or publish those forms. In my opinion it makes Nintex a much more enterprise ready solution at this time.

Mobile and Desktop Form Development

Currently PowerApps’s development experience is very much a mobile first design focus. Though Microsoft is in the process of rolling out PowerApps fully embedded in SharePoint lists (overriding the default form) it still uses a slim portrait view that is mobile ready. This could very well change in the future but there is not enough known about the roadmap at this point.
Nintex gives you a number of choices around how your form should be displayed. In SharePoint you can use their classic mode which allows you to design different layouts depending on the users’ device. Thus, your form on a desktop would look much different than on an Android phone, for instance. This design style allows you to customize each form by writing JavaScript to create complex forms.
Nintex also just released a Responsive Design experience, which is even easier to use and is targeted to business users who want to create forms without any knowledge of coding. The resulting form is completely responsive so looks good on a desktop or a phone and it intelligently stacks the fields and labels based on the device’s window size.

Native OS Controls

This is a small difference, but worth mentioning: Nintex forms will use the native controls for your mobile devices. That means you’ll get the iOS date picker on iOS and the Android date picker on Android. With PowerApps you’ll get the same controls across all devices which can lead to potential usability frustration for some users on mobile devices.

Cloud, On-Premise and Offline

PowerApps requires you to use the cloud based offering. There is no on-premise installation (or plans as of yet) that allows you to run your PowerApps in your own environment. You can connect it to your on-premise data using a data gateway which must be installed and configured on your on-premise servers. Nintex has a SharePoint 2010, 2013 and 2016 version that all install into an on-premise SharePoint environment.
Additionally, offline usage for PowerApps is difficult at this time, though possible. Nintex Mobile handles offline form submission and task completion very efficiently, queuing up data to send once your connection is restored.

Complex Forms

Nintex’s Classic form builder allows for complete extension through JavaScript, which, combined with custom REST services means you can pretty much make it do anything you want. PowerApps also allows for very complex form build using custom connections to your data and Azure Functions. At Microsoft Ignite 2017 Microsoft talked extensively about this tool not having a development “cliff” which is where you realize the form tool is no longer powerful enough to handle what you want to do and if you want to achieve your goal you have to start from scratch building a new form from the ground up (custom development for instance).
I do find that in building forms in PowerApps you have to rely on the controls and the functions that PowerApps gives you so you’re at the whim of what the tool can do, or have to work creatively around the limitations, as opposed to the vast ability of JavaScript which is well known by many developers. That being said, Nintex Classic Forms experience is only available in SharePoint (both on premise and online), which means your complex forms would live in SharePoint. PowerApps (soon) will also have the ability to surface in a SharePoint list or library, but since it was developed outside of SharePoint first it has an advantage, which bring us to:

Stand Alone, Form Based Applications

Here’s where PowerApps really lives up to its name and has a strong advantage over Nintex. If you’re looking to build a standalone application that maybe doesn’t even connect to SharePoint, PowerApps may be a good fit. It has the ability to connect to a ton of data sources, including the Common Data Service, allowing you to build mobile first, line of business applications a lot faster than you could in the past. You can get Nintex to do this, but it’s not as intuitive as doing so in PowerApps.

Nintex Workflow vs Flow

In this section I’ll mostly focus on a comparison of Nintex Workflow for SharePoint (online and on-premise) and Flow but I do mention NWC a little bit. I expound on NWC a bit more in the next section.
User Experience
Since Nintex’s introduction their focus has been on creating an extremely easy to use workflow creation tool. Compared to SharePoint designer it was no competition, Nintex won every time. Flow closes the gap a bit, but Nintex still does have an edge in their user experience.
Neither tools use your standard BPM Notation, so both do require you to think a bit differently about your workflow. Nintex’s recommendation has been to stop diagraming your workflows in Visio and instead just build them directly in Nintex. This way when the flow looks right you just have to make it functional, half the work is already done. I’ve seen this be very successful and the same could be said for building a workflow in Flow.
In my experience, Nintex handles variables and transferring of data from one action to another a bit more intuitively than Flow does. I prefer the action pane Nintex provides for dragging and dropping actions compared to Flow’s add button and search for action model, but I can certainly see others liking Flow’s experience better.

State Machines

State machines allow you to create a workflow that doesn’t have a single, straight forward path. Imagine a workflow where there is an approval step. If rejected a task gets assigned to the submitter to review and resubmit. This workflow could go through any amount of iterations of this approval cycle. State machines make this easy to define in a workflow process and Nintex wins big here. Currently there is no way to easily create a state machine workflow in Flow, you have to work around the limitation.

Who Owns the Workflow

Similar to PowerApps, Flow’s are owned by a single individual or account. In Nintex the workflow is owned by that list, library or site. See “Who Owns the Form” above for more details on my opinion here.

Simple Looping / Conditional Evaluations

Looping is possible in Flow, you can do a For Each and a Do Until. This is much better than what SharePoint Designer provided (even the latest 2013 iteration), however they’re a little clunky to work with. Nintex gives you three looping types, For Each, Loop with Condition and a Loop N Times. Setting them up is pretty intuitive and you can create some complex looping if necessary.

Cloud and On Premise

Just like PowerApps, Flow is only cloud based. This means your workflows will only run in the cloud and to access on premise data you need to use a data gateway. Nintex installs into SharePoint on premise or runs in SharePoint Online in the cloud.

Feature Sets

Both Flow and Nintex have over 100 actions with 10s of connections to other systems. You’d be hard pressed to do an exact functionality comparison of all innate actions or 3rd party connections (a task for another day). If anything, at a high-level glance it feels like Flow may have surpassed Nintex in their off the shelf 3rd party connections from a quantity perspective. That being said, both have the ability to make REST calls, so any connection that doesn’t already exist can be made through API calls from both.

Document Generation

Due to Nintex’s acquisition of Drawloop, Nintex has a document generation feature built right in to their workflow tool. The user experience is intuitive and you can quickly create a document template, map properties from your workflow into the document and quickly be generating Word or PDFs. Flow has no innate functionality for this (though you could probably build it using REST calls to a 3rd Party Doc Gen company like HotDocs – For any process where a document needs to be generated, Nintex has a big advantage here.

Initiation Options

Flow uses pre-built 3rd Party connections or a scheduling service to initiate workflows. There are quite a few events from connections already built (169 triggers at time of writing). It’s worth taking a look through them just to see what’s possible, as the list is quite impressive.
Nintex has a few options for initiation. With the SharePoint workflow platform, it’s your standard list/library item created, modified or manual start. There is also a scheduled site workflow option. Nintex Workflow Cloud extends the initiation capability to much more, using the idea of connections similar to the way Flow does. The number of off the shelf connectors are less than Flow, however there are two things to note in NWC
One, is the ability to create a form as the imitation of the flow. This gives you the ability to use the Nintex Responsive Form builder to build a form that can be anonymous and either browsed to directly or embedded in any website.
Two, is the ability to have your flow be externally started. When this is selected and you publish your workflow you are given a REST endpoint with instructions on how to call that endpoint from ANY other system. That means you can start a workflow from any code or system that can call a REST endpoint. I’ve even seen NWC workflows kicked off from a Flow workflow.

Nintex Suite – Additional Features in the Suite

When you purchase Nintex using their subscription pricing you get access to Nintex Workflow and Forms for SharePoint (On-Premise & Online), but you also get access to their Nintex Workflow Cloud and, depending on your subscription level, Nintex Hawkeye which provides functionality above and beyond forms and workflow. These are included in the package so it’s important to factor them in when discussing cost justification.

Nintex Workflow Cloud (NWC)

Not all workflows make sense in SharePoint. That’s why Nintex created NWC, for those times you want to automate a process but it doesn’t have anything to do with SharePoint. Comparatively, NWC is much more like Flow than Nintex workflow in SharePoint. Both are cloud based, both use connectors for initiation and interaction with other systems. NWC has their form builder and external start as a differentiator as well as a different user experience that I find to be more intuitive. There is also task assignment and management in NWC, which you don’t get with Flow. All of the differentiators that I discuss above for Nintex for SharePoint vs Flow also apply to NWC vs Flow.


Hawkeye is a business intelligence tool that will help you get a better understanding of what workflow is doing for you and how you can get more out of it. With Hawkeye you can inspect your workflows as a whole (across all Nintex environments cloud and on premise) and see inventory, usage and many other statistics. This allows you to track your ROI, manage the health of your workflows and identify places for process optimization in existing workflows. To help with this latter point, Nintex Workflow contains some Hawkeye actions that let you log information to the Hawkeye database which you can then use for even more granular analysis and optimization. Depending on how much time you want to commit to continuous improvement, this can become very powerful and for the right process help you identify ways to save thousands of dollars.
All the data from Hawkeye is viewable from prebuilt Lenses (which use PowerBI) or can be accessed raw and imported into your favorite data visualization tool like Tableau.

App Studio

Nintex Enterprise edition allows you to publish Nintex Forms as actual branded apps that can easily be downloaded and installed on mobile devices. Imagine having your company time-off request app on all your employee's phones, giving them the ability to easily submit their requests at any time, and then initiating a workflow. They'd never know it was Nintex that was powering it as you get to completely brand it as yours.

App Studio also gives you the ability to push content to your employees through these apps. For example you could push out the employee handbook or time off policies in the same apps as the time of request form. This puts the information right where it's needed.

Final Note on Nintex

Workflow, Forms, Hawkeye, NWC & the App Studio; all of these things are Nintex’s bread and butter. They are an established company with a good vision and they will continue to iterate on these products. PowerApps and Flow are just a small piece of the Microsoft suite. Admittedly Microsoft shows a very strong commitment to these platforms, however at any point in time they could discontinue them and go a different direction (Anyone remember MS Access’ return to fame in SharePoint 2013?).


Hopefully this (longwinded) article helps you to better see the strengths and weaknesses of these products from a features perspective. I do believe that each use case needs to be evaluated on a case by case basis and there are certainly times when PowerApps and Flow are a great fit. The other times you can rely on the Nintex Suite to provide your company great value for automation and form creation. I have personally found with many clients that the above differences are enough to justify the cost of Nintex and when a company adopts the platform, there is always a return on investment that outweighs the cost.
Though I’ve worked with all these products extensively I’m certainly not perfect. Additionally, they are both changing rapidly, so it’s possible this information will go out of date the day after I publish it. Due to these two facts, please feel free to reach out to correct or update any of this information. I hope this can remain a good reference for customers considering Nintex, PowerApps and Flow. I’m also open to discussing any of these topics in more detail so please feel free to reach out to me if you’d like to discuss your particular use case and I can help guide you based on my experience.

This post intends to demonstrate how a JavaScript/JQuery function can populate a calculated value control dynamically within a Nintex Form. Accessing data by using REST API Service makes dynamic content compulsory.


Here is the form view that shows unpopulated calculated value controls as following.



In order to resolve this issue, I have decided to force calculated values to be recalculated by JavaScript code.To accomplish this, we need to setup following steps.

  1. Define a textbox with the name of 'hiddenField' and set « Store Client ID in Javascript variable » to Yes and give the value of « Client ID Javascript variable name » as 'hiddenFieldPageID'.
  2. Then all our calculated values formula should be included with a reference to the textbox.
  3. In our calculated values, add a reference as a parameter that does not be used in our Javascript method.
  4. Ensure the formula is set to getLabel("lblSecondLang1",hiddenField).
  5. You will be able to force a calculated value to recalculate by calling these following lines of JavaScript code.

            var hiddenTextBox = NWF$("#" + hiddenFieldPageID);


The calculated value settings as shown below.



If you noticed, I have added the 'hiddenField' control into the fuction as a parameter, which causes the calculated value is triggered when the control has been updated. Finally, calling of JavaScript function ProcessOnChange refreshes the controls' value again.



calculated value control dynamic population resize at runtime

This blog describes how to enable "Document Generation" feature on SharePoint 2013 on-premise server.

Prerequisites: Nintex Live is installed and running on your farm.

  1. Go to Central Administration > Nintex Workflow Management > Nintex Live and external Settings
  2. Click on "Enable" next to "Enable prerequisite service" on top.
  3. Under Nintex Live heading, click on "Activate" next to "Document Generation capability" feature.

The above steps makes the "Document Generation" feature start and running.

Now, you have to add "Document Generation" workflow action to allowed workflow actions on your farm.

  1. Go to Nintex Workflow Management > Manage allowed actions
  2. Check/Select "Document Generation" workflow action.
  3. Click on "OK".

Now, make sure you see "Document Generation" workflow action available for use. For that, create a workflow and from workflow actions, type in "document generation" or go to "Lists and Libraries" category, you see the "Document Generation" workflow action available.

Sometimes we have disconnected data in our form that we do not require in the underlying list, but may need as part of our workflow process.

In this example I show you how to utilise the very helpful Form Data available in Nintex Workflow to pull information from the form that submitted the data in the first place.


List Settings

  • Custom list with title field as standard called "FormDataDemo"


Form Settings

  • Customise the "FormDataDemo" list using Nintex Forms
  • Add Single Line Textbox control to the form with the following settings:
    • Name:  UnconnectedTextBox
    • Connected to:  Not connected
    • Data type:  String
  • Publish the form


Workflow Settings

  • New nintex workflow on list "FormDataDemo"
  • Start when items are created
  • Query XML action:
    • XML source:  XML
    • XML:  {ItemProperty:FormData}
    • Output 1 - XPath:  /FormVariables/UnconnectedTextBox
    • Store result in: New variable "vTextUnconnectedTextBox"
  • Log in history list:  vTextUnconnectedTextBox



Of course you are likely wanting to work with that value, not just log it to history list, but this was just for demo purposes and to help resolve a question asked on the community.

Each month, we like to highlight valuable community members and name them to a monthly honor roll.  Just hover over their names and click "follow" or visit their profiles and follow them there to get their activity in your news stream in the community.


This helps expose you to how active community members are engaging with other Nintex users.  You'll see what content they're creating, and responding to.  It's a great way to enrich your community experience.


For October, we have a nice mix of new and existing community members.  A couple of call-outs:

Tom Castiglia is a long-time community member and Nintex Partner.  His answers to people's questions are always helpful, but Tom's also blogged a couple of times in just the last month. Visit his profile page and click "content." to see his blogs. Tom, thank you!


Vincent Cabral is the VP of Product for Nintex Drawloop. He's a frequent visitor to the community, answering customer questions. I don't think it's often that a VP at any company takes the time to interact with customers at the community level. I think it speaks to the person he is and the kind of company Nintex is.  Vincent, thank you!


Nintex Technical Evangelists have been creating great content for the new Nintex Product Blog. It's THE place to get the latest information the features and capabilities of the Nintex Workflow Platform. Many thanks to those listed below! Follow these guys!


And thanks to customersRamana Thakkallapally and Clavin Fernandes who've been members for about a little while, but recently dove in to provide some really helpful replies. It's a perfect example of community give and take.


See the entire list below. Thank you all for your answers and contributions to the Nintex Connect community!


This month's Honor Roll members to follow:


Congratulations and thank you to all of this month's Honor Roll members!


honor roll big


Honor Roll members will get this badge in their reputation center, along with 100 points.


This is not just open to the whims of the community manager! If you'd like to nominate someone for the honor roll next month, send me a message: or ping me via the community!

Though I have been working with Nintex Forms and Nintex workflows for a long time I didn't happen to realize how versatile and fun to work with repeating sections on the forms in conjunction with Nintex workflows. Long story short, I always had this common requirement from Infopath form days till a new project I implemented purely with Nintex, that is none other than having an ability to report and update the repeating table rows using spreadsheet view in the SharePoint.


Until I come across a great post written by Vadim Tabakman parse repeating section data I felt it is not possible help clients with such requirements without code, but Vadim Tabakman's posting changed the way how I looked at NIntex Forms. Though the idea of parsing data taken from his post, I wrote the workflow steps in little different way to not to use the loop action instead stick to for each action due to loop action being dependent on turning off safe looping setting which I personally dislike taking that setting off.



Repeating section rows will not come with row numbers, and also they can not be appeared in direct list columns because of the their one to many nature. Thus not allowing it for edit in excel mode.



The direction I am taking to address above is create a child list and main the repeating table data in the child list while storing their item IDs in the repeating table hidden rows for later use of update. while my project was pretty complex with bunch of look up fields and all data types like dates, numbers and persons, for the easier understanding of concept I created  a separate project and will make use of that here. 


We need two simple lists for implementing the solution. First list I am naming NintexPOC for keeping it simple with just 2 columns 1. Title  2.MyRepeatingData - mulitline text plain.

Second list I am naming as Expense Records with 4 simple columns such as 1. Title 2. Expense Date 3. Amount and 4. ParentItemID(this is a look up field from NintexPOC to maintain parent child relationship).


Part 1: Now let us start with key element of the solution, that is our form with repeating section. I placed the names of each control in the repeating section in red font on the screenshot for readability. Provide your repeating section a name and also connect it to the multi-line text field we created in the list. Inside repeating section also keep a control for storing child list item id and make it hidden if you don't wish to display it to the user.

Once you connect the repeating section to multi-line text field and publish, create your sample data to give a peak at how Nintex generating the XML  for us. when you save an item at least with one repeating section row filled with data this is how it is going to look like.

NintexPOC - All Items

<?xml version="1.0" encoding="utf-8"?><RepeaterData><Version /><Items><Item><EName type="System.String">User2</EName><ExpDate type="System.DateTime">7/3/2017</ExpDate><ExpAmount type="System.String">500</ExpAmount><ChildItemID type="System.String">10</ChildItemID></Item><Item><EName type="System.String">UserOne</EName><ExpDate type="System.DateTime">7/25/2017</ExpDate><ExpAmount type="System.String">100</ExpAmount><ChildItemID type="System.String">7</ChildItemID></Item></Items></RepeaterData>

Part 2: Now its time for us to switch to workflow part of our solution which is where the greater possibilities with Get XML action and collection objects unfold.

As a step 1 simply get your multi-line text field data into workflow variable and add regular expression action in the workflow right after that. Configure the Regular expression step like below

For the purpose of building for loop action we need one dummy text field, we will use this only for setting up in for loop action box and won't use any where. Also create a number field with name Index and set default value as 1 to start with. This index variable is the key in the next steps. inside for loop we will also be keep doing increment it by 1 in each iteration.


Inside for loop action, now add Query xml action and add output blocks like below until you get all your named controls to variables. 


we will check if child item id is blank, if not blank that means we have an existing item so can update instead of creating new. If child id doesn't exist then create new item and get the newly created item id and store it back in the xml field with Update XML action.


End of workflow update current item with updated XML back to our multi-line text field. Now that we have each repeating row assigned with its corresponding list item id, when the child list items change we can use item updated workflow and update that specific row in the repeating row. It is much simpler workflow without any loops and explaining it here would be too boring to read  . Attaching full solution for download including list templates and both workflows.

Filter Blog

By date: By tag: