Use SharePoint Designer to Email Daily Task Reminders

ByMarc D Anderson

Paul Galvin has written a very nice article over at the new SharePoint Magazine about how to set up daily email task reminders just using SharePoint Designer.  The article is well written and shows how you can get something done that you might have been sure you needed to go to Visual Studio to accomplish.

The comments (so far) are interesting, too.  Several people (furuknap and Nikhil) express concern about trying to do this sort of thing in Designer.  I understand their point, but if taking this approach brings relatively simple workflow more in the reach of Designer users, then I’m all for it.  Paul points out several issues with using his methods, and as long as you are aware of them, you ought not be afraid of the approach.

Paul also hints at several ideas he’s holding for other articles:

  • Workflows "cannot be easily ported anywhere, period. There are clever workarounds to this problem, but that’s for a future article. (Hint -edit the XOML file directly, replacing task, list and other GUIDs manually.)  This analogous to the way that I copy or move DVWPs around from place to place, should I need to.  In fact, at this point, I almost always switch from ListIDs to ListNames in my DVWPs.  The XOML files are just XML files like everything else: to edit them in Designer, right click on them and open as text.
  • With this approach, "it would be hard to decipher the history and require a lot of clicking.  There is a clever solution to this problem as well, again for a future article. (Hint – create entries in a custom list using a common key field to group them together.)  Having workflow events add new entries to other lists can work well, but you do need to watch out if this is going to cause your lists to have thousands of items. The rule of thumb out there is that list objects (roots of lists and subfolders) shouldn’t contain more than 2000 items each.  I haven’t seen going beyond this limit (even greatly) be a problem, but it’s something to watch out for.

Similar Posts

2 Comments

  1. Bjorn:
     
    Tanks for your comments.  I’ve worked with quite a few clients who have real difficulty in deploying custom managed code, usually because it requires a much more rigorous QA and UAT lifecycle.  In some instances, the middle ground of SharePoint Designer allows them to get good functionality in place much more rapidly.  In many cases, building the functionality actually makes more sense anyway, as it becomes more end-user manageable.
     
    However, I’m in agreement that one shouldn’t use whatever hammer that they have on hand to solve their requirements.  I do happen to believe that much good work can be done in Designer with custom forms, DVWPs, and Designer-based workflows.
     
    M.
    Reply
  2. The point of my comment and concern was not with the method per se but rather using SharePoint Designer for everything. I absolutely agree that this is one approach more available to some users than learning workflows the developer way. I’ll even agree that this is not a ‘hack’ in any sense. It is, however, not very scalable and, as Paul says, absolutely not portable. A lot of things _can_ be done in SPD, but that does not mean it _should_ be done in SPD.
     
    Simple in the short run, yes, but perhaps it brings more misery and cost in the long run. For a one-time thing that will never be used again, go ahead, this is a great solution. If there is a chance that your will use the solution again and again or something happens and you need to debug the process, well, you are out of luck and may very well end up spending more time fixing the problems than solving them ‘right’ in the first place.
     
    Bjørn Furuknap
    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.