Create single notifications for owners of documents in a library when due for review

If you don't currently, add a column to the library that identifies who is the owner. Then in your site workflow you use a query against the library looking for all documents that set to owner "Jim A", do for each and then in the for each loop grab the document URL or Title or whatever other information you want to display, and then add it to a multi-line variable. In the end a notification with the multi-line variable in the body. Screenshots below. I haven't fully tested this, but it should get you to at least 90% of the way.

I'm not sure how what you replied with and what I showed above are different. You query all documents where column "owner"(or whatever you named it) is equal to whoever, and then loop through each one gathering whatever details about the document you want(whether just the title, or as well as the file size, created date, etc.) and then put them all together in a multi line and send a notification outside the loop at the end with those details.

Right, so what I've shown can show you how to iterate through all documents for a specific owner. Now what you can do is before doing this aspect, do a query for all the owners in the library. Do a collection operation to remove duplicates, then do a for each with the remaining owners collection.

So essentially, you would have three for each loops, one to gather the list of possible owners. Then you have one to iterate through each owner, querying for all that owners documents, then your third for each runs inside the second one to build the list of documents for that owner. Then when that's complete, it exits the third loop, finds the next owner, and repeats the document list building. 

If it's confusing reading it I could design it out in a workflow.

I can do that. Can you show me what you have so far(as well as the library you are looking into for the workflow) and I can maybe spot where we got mixed up?

I began building a demo of it, and I realized I led you astray. You do not need the loop for the owners. A simple query against the list, for all items, grabbing only the Owner column and then putting it into a collection variable will give you all of your owners. So the issue of not returning any owners should be resolved from there. 

Also, if your owner column is a people column and you're able to collect the owners but not match documents to owners, try looking at @emha post here: https://community.nintex.com/t5/Nintex-for-SharePoint/How-to-you-filter-results-within-a-Query-List-action-by-assigned/m-p/7351/highlight/true#M6204

Hmm, no, you're not doing anything wrong. I guess I hadn't fully thought out the notification part inside the loop so I didn't really explain it.

We need to be able to do the notification IN the loop, or else it sends just one at the end like you experienced. But we can't have it run EVERY loop because then it sends one per document. How annoying!

So we need to only send the notifcation SOMETIMES. Maybe. Possibly. CONDITIONALLY! :manvery-happy:

I'm sure there's cleaner ways to do this, and plenty of people here could write it better, but this should work without issue. Add an additional variable just like your targetOwner(I'm calling it this, but you call it whatever you need), but let's call this one something like buildingOwner or ongoingOwner. Name isn't important as long as it makes sense to you. 

Throw a condition at the top of your loop. Tell it if buildingOwner is empty, set it to targetOwner(the single result of your for loop running against the collection of owners).

Now put a condition right above your build string. Compare the values of buildingOwner and targetOwner. If they're different, send the notification; if not, build string.

Basically, what we're doing is at the end of every loop we're looking to make sure we're still operating on the same "owner". If we are, we skip through the condition, and we just keep on building that list of documents. If the owner changes, then we send the notification, we clear the build string(explanation below), then we do our build action.

One thing I didn't note previously, you have to make sure to clear the value of your build string variable, or else you'll send the last guy every single document as it just continues to build. Below is a screenshot that should get you working. 

So in order, with the screenshot above: For each owner, we check to see if the buildingOwner is emptp and set it to currentOwner if so. We get all documents, log those to history(remove this later if you don't need it past the testing phase. It could eventually be a lot of extra text in the history list depending on number of documents down the road), check if we're on the same owner and if so we continue the build string. If not, we send the notification, wipe out the build details so it's ready for the next owner, and then put the first document detail into the build string. Repeat.

After much trail and error I finally got it to work! It starts by getting all the owners and removing duplicates. Then get the ID's of the documents in the library due for review. The for each ID get the title, review date, URL and put them in collections. (tidy the data up a bit) Put the data into a string then build the table with the string. Finally send the notification to the users in the Owner collection :)

A copy of the final workflow is below;

1. Create a list workflow which will notify the document owner to review the document
2. Now create a site workflow which will:
   1. Query your list and get IDs as collection
   2. Using for each action for IDs collected, schedule a workflow on each list item
   3. Try to use service account which has been stored as Nintex constant to run the web service