- January 2017
- May 2016
- April 2016
- January 2016
- December 2015
- November 2015
- October 2015
- September 2015
- August 2015
- June 2015
- May 2015
- April 2015
- March 2015
- February 2015
- January 2015
- November 2014
- October 2014
- September 2014
- July 2014
- June 2014
- May 2014
- April 2014
- March 2014
- September 2013
- August 2013
- July 2013
- June 2013
- May 2013
- April 2013
- March 2013
- February 2013
- January 2013
- December 2012
- November 2012
- October 2012
- September 2012
- August 2012
Monthly Archives: March 2015
My SharePointBuddy (Sandra Mahan) and I were brainstorming stuff recently, and the topic of SharePoint 2010 looping workflows came up. To the best of my knowledge, you can’t create a workflow in SharePoint Designer (SPD) that will repeat an action for an unspecified number of repetitions (occurrences or days). Basically, the workflow is linear in nature, and it runs from top to bottom.
But what if there was a way to get a workflow to repeat a certain action until a condition caused it to complete?
I think we found one! A disclaimer up front, though… For all we know, this may be common knowledge, and your reaction might be “well, duh!” In that case, you’re dismissed from reading the rest of this. We just thought it was a cool concept that could work nicely in a number of situations (and with no drawbacks that we know about… yet).
The concept is this… Create a secondary list that triggers workflows that affect your primary list. The primary list item creates a secondary trigger list item, and the secondary trigger list item deletes itself after updating the primary list item (which potentially triggers the creation of another secondary list item, and so on).
Confusing? Sort of… Let’s see if I can flesh out an example here based on my testing.
I have a Non-Disclosure Agreement (NDA) list that tracks the creation and completion of NDAs. When the NDA list item is created, it sits in a status of Pending until a copy of the signed agreement is attached. The status then goes to Completed.
While the status is Pending, the customer wants a reminder to be sent out to the NDA owner every 15 days reminding them to submit a signed agreement. The notices only stop once the NDA list item is marked Completed.
My current (non-repeating) workflow in SPD starts a reminder process when the NDA list item is created. It waits 15 days, then it checks the status. If the status is still Pending, it sends out the reminder email and waits for another 15 days. If the status is Completed, it stops the workflow. Since the workflows in SPD are linear, I have to repeat the reminder email action over and over for each 15 day period. I run it out to 180 days, and then I exit the workflow (I had to draw a line somewhere). It works, but it’s far from elegant.
Now let me rework it using the looping concept…
I still have the NDA list, but I no longer start the reminder workflow when a new NDA is created. I add one more column to the NDA list, and call it Reminder Last Sent Date. The only other relevant column for this concept is the Title field in the NDA list, as that’s what I’ll use as the key to match to my new workflow triggering list.
I create a new list, and I call it NDA Reminder Triggers. The only column in this list that I need is the Title column, which is the key to match back to the NDA list item.
Now for the workflows…
I create a new workflow for the NDA list that is triggered on a created or changed item. The workflow checks the status of the NDA. If the status is Pending, it creates a new NDA Reminder Trigger list item with a Title field that matches the Title field of the NDA, and the workflow exits. If the status is Completed, the workflow exits. The goal here is to make sure there is a NDA Reminder Trigger list item for each NDA item that is in a Pending status.
For the NDA Reminder Trigger list, there is a new workflow that is triggered by a created item. That workflow starts by waiting for 15 days. At the end of 15 days, it checks the status of the NDA list item (matching on the Title field). If the status is Pending, it sends a reminder email to the NDA owner (again, a lookup to the NDA item via the Title field), updates the NDA with the Reminder Last Sent Date field set to Today, and it deletes itself. If the status is Completed, it just deletes itself.
The act of updating the NDA list item with the Reminder Last Sent Date now triggers the NDA list workflow to create a new NDA Reminder Trigger list item. The new NDA Reminder Trigger list item triggers *that* list workflow to wait 15 days before checking the NDA status again. This cycle can repeat as long as needed for the NDA status to be set to Completed.
In my preliminary testing for this idea, it seems to work fine. If I update the NDA list item status while the NDA Reminder Trigger item is waiting in the 15 day workflow, then when the 15 days is up it sees that the status is now Completed, and the NDA Reminder Trigger list item deletes itself. If the NDA list item is updated once the status is Completed, the NDA list workflow doesn’t create a new trigger item.
Thoughts? Comments? Hidden landmines we don’t know about? I’m happy to get your feedback…
A recent help desk case took me longer to resolve than I expected, mostly because what the error message said and what I thought it was saying were two different things. A customer called about a spreadsheet that was being generated by SSRS, and they were thinking they weren’t seeing all the data due to Excel showing an error saying it couldn’t filter more than 10000 rows. I’ll admit I was a bit concerned, because this spreadsheet would *always* have more than 10000 rows, so what’s the problem?
I found my answer here:
That message refers not to the number of rows displayed in the spreadsheet, but the number of items that appear in the column filter dropdown. For instance, you’ll see all 28000 rows in the spreadsheet, but you see that 10000 rows message when you click on the dropdown for the filter:
That 10000 refer to the number of entries you would see under the (Select All) line of the checkboxes. It simply means that you would not be able to see all 28000 items in that filter list, but you’d still see all the rows of data in the spreadsheet.
A better example would be the dropdown for one of the date/time fields:
If the filter list just had YYYY/MM/DD, you would have maybe 1000 unique dates over the last three years. But since it goes down to HH:MM:SS, close to every one of the 28000 rows has a unique date/time combination. The filter can’t show all those unique values, so you get the error message. You could still use the filtering to find all 2014 items for January through May, but you couldn’t drill down to also refine the filter to the exact times because you couldn’t show and expand all those combinations.
Basically… all the data is there. Nothing to worry about…