SharePoint Duffbert

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…

I had an interesting question posed to me recently. Someone wanted to create SharePoint alerts on a document library, and they wanted it scheduled to run weekly on all new items. In addition, they wanted to send the alerts to a distribution list so that they didn’t have to maintain separate alerts for each individual. That all sounded well and good, as editing alerts (other than to just delete and recreate them) is not possible without 3rd-party tools.

I created the alerts and tried to send it to a distribution list we had set up in Active Directory (AD). Unfortunately, the alert emails never showed up for anyone on the list. I tested the alert with it going to me specifically, and that worked fine. So why wasn’t the distribution list working? I’ll admit, I was stumped…

Some research got me to the answer that I didn’t want to hear. Distribution lists in AD can only be used in alerts if they are also set to double as security groups in SharePoint. That’s problematic for us, because our security area doesn’t want distribution list AD groups to also be used for security purposes.

I toyed around with other ideas on how to get the equivalent of a weekly email of new items in a library to send out to a group, but each option had some drawbacks. SharePoint Designer workflows would only send one item at a time, and our SQL Server Reporting Services (SSRS) configuration doesn’t have the email service turned on. The customer could send an email to everyone once a week with the new items in it, but she doesn’t want to have to do that manually.

Bottom line… how can I get the alert feature to work for a distribution list?

My solution was to let SharePoint generate the alert to the customer, and then have the customer set up an Outlook rule to forward it to the distribution group. That way, we have nothing custom that has to be maintained in SharePoint, and she has full control over how often the alert runs and who it goes to.

Following are the instructions I sent her on how to set that up. I’m sharing it here so I won’t forget. 🙂

What I am suggesting is to set the alerts like you had planned (weekly on Wednesday and Friday), and address them to yourself. Then by using Outlook mail rules for those alert emails, you can forward it to a distribution list (or select individuals) of your choosing. Exchange and Outlook will run the rules regardless of whether you’re logged in or not, and people will get the alerts just as if they were individually subscribed. You can maintain the delivery list as it’s your rule, and we don’t have anything extra or custom to support in SharePoint.

 All the other ideas we had (workflows, Reporting Services, views of the last seven days of information) had various side effects that would either require extra work on your part or would mean extra clicks for the reader to see the actual list of articles. This approach maintains the value of the alert listing all the weekly updates, without the need to delete and recreate the alerts for individuals if anything ever changes.

Here’s how I set it up…

Go into the library (Articles Of Interest or New Learnings) and click on the Alert Me > Set alert on this library option: 

 Set up your alert as you normally would, routing it to yourself on whatever schedule is desired: 

 You’ll receive an email saying the alert has been created: 

 Once the alert is triggered the first time, you’ll get an email that lists all the items based on your criteria: 

 When that email comes in the first time, we’ll set a rule for those alerts. Click on Rules > Create Rule: 

 On the Create Rule dialog box, select Advanced Options: 

 Check the entry for the subject line phrase, and click on that phrase at the bottom of the dialog box. We are going to change the phrase: 

 Remove the You have successfully… phrase by clicking the Remove button: 

 Change the phrase to the name of the alert (in this case, Articles Of Interest) and click Add: 

 Once that’s done, click OK: 

 Click OK to proceed to the addressing part of the rule: 

 Select the action to forward the alert to people or a distribution list and click on the people or public group at the bottom of the dialog box: 

 Select your distribution list or the names of the people you want to have get the alert and click OK: 

 Click on Next to go to the Exceptions dialog box: 

 Since there are no exceptions, click Next: 

 Your alert is done. Give it a meaningful name, make sure the rule is turned on, and click Finish: 

 Next time you get the alert, it will come into your inbox like normal: 

 Moments later, that email will be forwarded to the distribution list: 

I’ve been working with SQL Server Reporting Services (SSRS) recently, and it’s been an eye-opener. I can now give my customers some spreadsheets on lists over 5000 items that are updated every day without intervention. It’s a game changer in terms of solutions I can design.

I did run into a frustrating problem, however. After a few days of my scheduled SSRS jobs running fine, I started getting an error: “Thread was being aborted”

There are many blog posts out there on that topic, but none of them seemed to relate to what we were seeing. After playing around a bit, I found that we were likely getting the error due to a time-out error for our job running too long. When I removed the server time limit for that job, things ran fine.

To do that, select “Manage Processing Options” on the report configuration:

In the “Processing Time-out” section, select “Do not limit report processing time-out”:

I’ve since adjusted the “Limit report processing time-out (in seconds) to” setting to 7200 seconds (two hours) so that there is *some* level of control for run-away jobs. Still, it’s nice to know that I can control this with each individual job now.

This is a presentation for our internal SharePoint User Group on Friday, October 17th, 2014. It is targeted to help them understand the Navigation, Versioning, and Advanced settings in their lists and libraries..

Presented to our internal SharePoint User Group on June 13th, 2014.

Sometimes we run into common questions or misconceptions about SharePoint. This is a tongue-in-cheek way to address these issues and let people know how things actually work.