Nintex O365 DocGen: Table in Excel only returns first row
Gang, I’m about to lose my mind. I have an existing O365 workflow with a DocGen that creates an Excel file with a table using the row as the repeater. The production one works like a charm. Now I’m busy with a new build on the Dev site where I’ve basically rebuilt the prod workflow from the ground up, adding some new stuff, cleaning up performance issues, etc.
The DocGen function on Dev uses the same template as the one on prod (as in, I downloaded it from Prod and uploaded it to Dev exactly as it), it’s using the same data to populate the collections, the collections themselves are returning the same data, but the DocGen on Dev (which, as I already said, is using literally the same template as Prod) only generates the first row of the table. I can’t see anything else in the knowledge base that describes this exact problem, so please, please, please tell me someone else here has run into this before.
Page 1 / 1
Hi @fairpoint
One simple way to verify is to export the Production Workflow and import into the Dev site. Check whether you need to configure any settings for the Dev site. Run the workflow - Does it generate the repeating rows? If it prints the repeating rows → you may have missed one or more configuration steps. If it does not print repeating rows → possibly the Dev site SP List may have insufficient records
Anyway, did you configure the Table Data configuration? This is the configuration for the Repeating Data
As I mentioned, I’m busy with a bunch of changes in the Dev space, which means the Prod workflow will no longer run on the new list.
As for the table config, that was done the exact same way I have done many times before and this is the first time I have ever run into this issue. When I print the data from the collections for the columns into the history, each column returns exactly the data (number of records and content) I’m expecting to see, so it’s not a source data problem. And if it was a tagging problem on the template, why would I get back the first row at all? If there was a problem with the tagging on a column, I’d expect an empty column at the very least, but the first row is perfect.
I have to admit, it’s extremely vexing.
I’m not sure what you mean by “possibly the Dev site SP List may have insufficient records” - could you explain?
Hi @fairpoint
Ignore this - What I wanted to know is where is the repeating data coming from?
I’m not sure what you mean by “possibly the Dev site SP List may have insufficient records” - could you explain?
You seem to be experienced enough to know what you are doing and you stated that you have done this many times before. From my experience, it probably a tiny misconfigured setting. Why not get another set of eyes to got through the workflow code?
Best way to investigate is to do a deep dive on another Dev site where you import the List and the Prod Workflow. Open 2 screen side-by-side and do a comparison. Best not to disturb the workflow on Production.
Hi @fairpoint
Ignore this - What I wanted to know is where is the repeating data coming from?
I’m not sure what you mean by “possibly the Dev site SP List may have insufficient records” - could you explain?
You seem to be experienced enough to know what you are doing and you stated that you have done this many times before. From my experience, it probably a tiny misconfigured setting. Why not get another set of eyes to got through the workflow code?
Best way to investigate is to do a deep dive on another Dev site where you import the List and the Prod Workflow. Open 2 screen side-by-side and do a comparison. Best not to disturb the workflow on Production.
Ah okay, that makes sense - thanks for clarifying :)
Yes, please, for the love of all things holy, do not mess with the Production workflow - the client is a financial services company and they’ll have my guts for garters :D
You’ve given me an idea for a roundabout way to get to a potential answer - which is just as well, since the straight approach is clearly not interested in co-operating. Let me try it out and I’ll report back.
@Garrett you’re not gonna believe this. I swear, this stuff only happens to me.
So eventually I created a small simplified test workflow on a completely separate list, separate template, separate library, everything. No relation to the workflow I’m working on at all. That one worked fine.
Comparing the tagging structures between the 2 (completely unrelated) files, I realized the table start tag in the Prod file was applied TO THE ENTIRE ROW. As in, not the span of the table you’re feeding data into - the entire row. I know, I know, it makes no sense, but there you have it.
So either the template I was working from WASN’T the live one from Prod (otherwise Prod wouldn’t work either), or some twinkle fingers slipped in somewhere along the way and messed up the start tag on my copy. Rebuilt the template from scratch, properly assigned the tags, et voila.
That’s 2 days of my life I will never get back. I feel very annoyed with myself and in serious need of a caffeine IV, so that’s the next thing on my to-do list.
Thanks again for being a sounding board. Your suggestion of a mirror testing site made me wonder whether I was just struggling with tunnel vision, which is why I decided to do a super-simple test using unrelated data - something new to look at. If I hadn’t done that, I may never have seen the problem.
Hi @fairpoint
Glad to hear that you manage to resolve the issue.
Sometimes when we are so focus on an issue, it blinds us to the glaring error that is right in front of us. Hence my recommendation of getting another set of eyes.
It may seems like you wasted 2 days but believe me in the long run the valuable experience will enrich you.
You are very lucky to have a new clean environment which you could rebuild the DocGen process step-by-step. Going back to basic freed you from your tunnel vision.
