- 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
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…
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…
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.
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.
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.
I have a really bad habit of “collecting” links to really interesting articles tweets, emails, and other stuff I want to read for my professional life. But unfortunately, I find it far too easy to get behind in the list, and pretty soon, it’s just a collection of things I’ve never read.
Time to put OneNote into play…
Taking a tip from Sandra Mahan, I’ve started putting the links into daily reading pages with To Do tags. The goal is to spend time reading at least five articles a day (I have to read a bit more than that to clean up my lists). As I cover my items and check them off, I not only keep myself more current on the latest SharePoint news, but I also have a history of things I’ve read if I ever want to track them down later for reference.
Today I got my Twitter Favorites/To Read list transferred over to OneNote pages. I’m working on email newsletters, and I also have to clean out my Pocket saves that are work-related. There are a number of SlideShare.net entries that need to make it out there also.
What I like about this method (in addition to the tracking and responsibility that’s built-in) is that I can have this list anywhere I go. It’s on my home computer, on my iPhone/iPad, and my work machine. Whenever I have a few moments, I can pick off one or two reading items and I know that will be updated throughout all my devices.
OneNote rocks, and I continue to find great uses for this tool…
FOR IMMEDIATE RELEASE
Combined Knowledge Expands International Training Offerings with the Acquisition of Mindsharp
November 3, 2014 — Combined Knowledge announces the acquisition of Mindsharp, the US-based SharePoint training and education company
|This historic move integrates two of the oldest and most respected educational companies in the SharePoint space under the same leadership. Post acquisition, both companies will continue to operate as independent business units, with Combined Knowledge specializing in UK opportunities and Mindsharp continuing to focus on accounts in North America.”Our customers are not looking for traditional training providers; they need highly specialized, global partners who understand real business challenges and who can build custom educational programs and roadmaps based on the individual needs of a business,” states Steve Smith, CEO of Combined Knowledge. “With this acquisition, we now combine the North American reach and brand recognition of Mindsharp with the products, services, and training courseware from Combined Knowledge in the UK to provide an end-to-end education and adoption solution for customers on both continents.
Combined Knowledge and Mindsharp training offerings and support services lead the industry in SharePoint educational content and are available worldwide via training partners and resellers, including Microsoft Gold Certified partners.
Available training offerings include:
“With both of these brands under one ownership, customers now have a single go-to supplier who can provide comprehensive training solutions,” continues Smith. “No other education provider in this sector can provide a comparable one-stop educational offering.”
For more information, contact:
About Combined Knowledge…
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.