How to Emulate User Roles in InfoPath Forms Services to Automatically Switch Views

Many of my SharePoint consulting clients and students express the need to have different users see different views of an InfoPath form. In the InfoPath client, this is easy to handle using the User Roles
functionality which has been well-documented elsewhere. Unfortunately, User Roles are not supported by InfoPath Forms Services for your browser-enabled forms. Here is a work-around that I have been using for quite some time that has worked well for me and my clients and students.

In this post we'll create a simple InfoPath form with two views: one view for most users and another view for administrators only. When the form loads, it will check to see if the current logged in user is an Administrator for that form and if he is it will display the Admin View to the user. If the user is not an administrator for the form, it will display the User View.

Create a Custom List to Store Users and Permission Levels

Although SharePoint exposes a number of web services that reveal security information and information about SharePoint Groups, I've never been able to get them to work reliably with InfoPath, especially without writing code. Since I can't use SharePoint Groups, I create a custom list to store the names of my users who will be administrators.

1. Create a custom list called My Form Admins.
   
2. Change the name of the Title column to Permission Level.
   
3. Create a new column named User, of type Person or Group. Set the Showfield to User Name.
   
4. Add a couple users.
   
5. Your list should look similar to this:
   
   

Create a New InfoPath Form with Two Views

Obviously, you'll need an InfoPath form to use this, so launch InfoPath and create a new blank form.

Within this form, create two views. Rename the default view to User View, name the other one Admin View. You don't have to add any fields on these views, but you can if you want. You will want to make them distinct so you know which view you are looking at, but it could be as simple as just putting the text "User View" and "Admin View" on the top of each view; that's what I did for this post.

Add Some Nodes to Store the Decisioning Information

In my form, I created a new group named AdminCheckingNodes, with two nodes both of type Text named Current UserUserName, and CurrentUserPermissionLevel. These will be used to store the User name of the current logged in user and his permission level, if one is set, in the My Form Admins list in SharePoint.

Add a Data Connection to the SharePoint List Containing the Admin Names

The form needs to be able to look at the My Form Admins list in SharePoint to determine the Permission Level of the current user. Create a data connection to this list.

1. Click on Tools, Data Connections.
   
2. Click Add.
   
3. Create a new connection to Receive Data
   from a SharePoint Library or List.
   
4. Paste in the path to the My Form Admins list.
   
5. Select the My Form Admins list.
   
6. Select both the Permission Level and User fields.
   
7. Accept all the other defaults in the wizard and close the Data Connection window.
   

Write Rules to Get the Current User's Permission Level

You need to write four rules to fire when the form first loads.

The first rule will store the name of the current user in the CurrentUserUserName
node.

1. Click on Tools, Form Options.
   
2. Select the Open and Save category.
   
3. In the Open Behavior section , click on the Rules button.
   
4. Click the Add button.
   
5. For the Rule Name, enter "Store Name of Current User".
   
6. Click the Add Action button.
   
7. Select the
   Set a field's value action.
   
8. For the Field, select the CurrentUserUserName node.
   
9. For the Value, click the Data Binding button. Click the Insert Function button, select userName. Click OK, and OK. Your form should look like this:
   
   
10. Click OK. The completed rule will look like this:
    
    
11. Click OK to close the Rules dialog.
    

Whew! That may have seemed like a lot, but it's only part of what we need to do. You still need to write three more rules. Your Rules for OpeningForms dialog should look like this.

1. Click the Add button.
   
2. For the Rule Name enter, "Clear out the current permission level". You need to do this just to make sure this field is empty in case the current user isn't listed in you're My Form Admins list.
   
3. Click the Add Action button.
   
4. Select the
   Set a field's value action.
   
5. For the Field, select the CurrentUserPermisisonLevel node.
   
6. For the Value, just leave the field blank. Click OK, and OK. Your form should look like this:
   
   
   
7. Click OK. The completed rule will look like this:
   
   
8. Click OK to close the Rules dialog.
   
9. You should have two rules now. You're half done!
   

   
   

The next rule will look at the SharePoint list and store the permission level of the user, if the user's name is in the list.

1. Click the Add button.
   
2. For the Rule Name enter, "Look up and store the current user's permission level".
   
3. Click the Add Action button.
   
4. Select the
   Set a field's value action.
   
5. For the Field, select the CurrentUserPermisisonLevel node.
   
6. For the Value, click on the data binding button.
   
7. In the Insert Formula dialog, click on the Insert Field or Group button.
   
8. Change the Data Source to My Form Admins (Secondary).
   
9. Expand out all the nodes and select Permission Level.
   
   
10. Click on the Filter Data… button.
    
11. Click the Add button.
    
12. In the first drop-down, select Select a field or group….Then select User, then click OK.
    
13. Leave the second drop-down with is equal to.
    
14. In the third drop-down, select Select a field or group….Then change the Data Source to Main, select the CurrentUserUserName node. Your condition should look lieke this:
    
    
15. Click OK on the next four dialogs. Your form should look like this:
    
    
16. Click OK three more times. Your rules should look like this:
    
    

You're almost done!. Just one more rule to write, then you can publish and test your form. The last rule will look at the value stored by the previous rule and will switch views if it contains the word "Admin."

1. Click the Add button.
   
2. For the Rule Name enter, "Switch to admin view if user is an admin".
   
3. This rule will have a condition to check the permission level you stored with the previous rule. Click the Set Condition button.
   
4. In the first drop-down, select Select a field or group….Then select CurrentUserPermissionLevel, then click OK.
   
5. Leave the second drop-down with is equal to.
   
6. In the third drop-down, select Type Text….Type the word "Admin" without the quotes; InfoPath will automatically add quotes for you. Your condition should look like this:
   
   
7. Click OK.
   
8. Click the Add Action button.
   
9. Select the
   Switch Views action.
   
10. For the view, select the Admin View, and click OK.
    
11. Your completed rule will look like this:
    
12. Click OK. All four rules should look like this:
    
13. Click OK twice to return to your form.
    

Publish and Test the Form

Now you're ready to test the form! Woohoo! The easiest way to do this is to switch to the User View, then click the Preview button. If you are not listed as an Admin in the My Form Admins table, you shouls see the User View.

Close the form, add yourself as an Admin in the SharePoint list and then preview the form again. You should see the Admin view.

Conclusion

You can do a lot more with this besides just switch views. For example, depending on the permission level you set for the current user, the form may call different web services to populate certain fields of information. You could choose to show or hide different sections using Conditional Formatting. When users with certain permission levels submit the form, you may have a SharePoint Designer workflow check to see if it was submitted by an Administrator, and if it was, do something different than if it was submitted by a regular user. The uses of this are limitless. Let me know in the comments how you plan to make use of this.

SharePoint Data Zoom: What the heck is NVelocity and why should you care?

A few weeks back I announced that we'll be releasing a free web part called the SharePoint Data Zoom Web Part. I'm happy to say that the web part was made publicly available yesterday. In my original post, I made mention of the NVelocity template engine, explaining that NVelocity provided the basis for creating scripts in Data Zoom. In this post, I'd like to give a little more background on NVelocity and begin to show you how the SharePoint Data Zoom Web Part is going to help you get your job done.
You may be asking yourself , "why would I want to use NVelocity for creating SharePoint web applications?". Well, NVelocity is a port to the .NET framework of the Java Apache Software Foundation Velocity project . If you are migrating an existing Java-based application to .NET, and the existing application was written with the Velocity template engine, then using NVelocity could make the migration process much smoother.
Not coming from Java? No problem. Like me, you may just prefer the template syntax of NVelocity over the syntax used in a normal ASP.NET Web Forms page. The Velocity Template Language was designed specifically for building HTML pages. Velocity provides you with a very clean syntax for performing common operations such as iterating over a set of database records and displaying each record in an HTML page. One could say that Velocity and NVelocity are Domain Specific Languages for HTML.
A while back, the folks at the Castle Project took NVelocity and branched it for the purpose of fixing bugs and making a few improvements. The Castle Project maintains the MonoRail code base, a popular Model-View-Control framework (MVC). As you may have already guessed, the "view" in MonoRail's MVC is provided by none other than NVelocity.
OK, let's move on to helping you get your job done with Data Zoom. What does an NVelocity script look like? Is NVelocity really that easy to use? Well, I'll let you be the judge. In the context of our SharePoint Data Zoom Web Part, here's a simple NVelocity example:

1 <div style="padding:10px">
2
3 #if( $user )
4   Hello $user.Name, welcome back to the '$web.Title' site.
5 #else
6   Welcome to the '$web.Title' site.
7 #end
8
9 </div>

The above example looks amazingly just like HTML, no? Of course, with the exception of some dollar signs ($) and an 'if..else..end' block. The dollar signs indicate variables, which are really .NET objects in disguise. In the SharePoint Data Zoom Web Part, we provide you with some SharePoint "context" objects to make your life easier. In this case, $user is the current web user, and $web is the current SharePoint web object (see line 4 and line 6). Thus, $user.Name is the name property for the current user, and $web.Title is the title property for the current web site. Piece of cake! It gets even better though. We’ve included a source editor with the Data Zoom web part that will let you create scripts from right there in your SharePoint pages. And just so you don’t have to remember all the names, properties and complicated syntax for intimidating SharePoint objects like “$web.Title” and “$user.Name”, we’ve created a menu system in the source editor which inserts snippets for you in just one click.
Here's a slightly more advanced example. In this case, we'll get the "Tasks" list from the current web site and display its Title, Created and Modified fields for each item in the list:

 1 ## Get the tasks list
 2 #set( $tasksList = $web.lists.get_item("Tasks") )
 3
 4 ## Get edit url information
 5 #set( $sourceUrlEncoded = $HttpUtility.UrlEncode($request.RawUrl) )
 6 #set( $editForm = $tasksList.Forms.get_item($PAGETYPE_PAGE_EDITFORM) )
 7
 8 #foreach($item in $tasksList.Items)
 9  #beforeall
10    <table class="ms-listviewtable" cellpadding="3" cellspacing="0" border="0" width="100%">
11      <tr class="ms-viewheadertr">
12        <th class="ms-vh2-nofilter">Title</th>
13        <th class="ms-vh2-nofilter">Created</th>
14        <th class="ms-vh2-nofilter">Modified</th>
15      </tr>
16  #odd
17      <tr class="">
18  #even
19      <tr class="ms-alternating">
20  #each
21        <td class="ms-vb2"><a href="$web.Url/$editForm.Url?ID=$item.ID&Source=$sourceUrlEncoded">$item.Title</a></td>
22        <td class="ms-vb2">$item.get_item("Created").ToString("d")</td>
23        <td class="ms-vb2">$item.get_item("Modified").ToString("d")</td>
24  #after
25      </tr>
26  #afterall
27    </table>
28  #nodata
29    No tasks found
30
31 #end

Lines such as 2 and 4 which begin with "##" double pounds signs are just comments. Read them or ignore them. On lines 2,5 and 6 we're calling the "#set" directive to assign values in our own user variables. Specifically, line 2 is where we get the Tasks list. On line 8, we begin a "for..each..end" loop that does the work of running through the Tasks list and printing each item's Title, Created and Modified field values. Slightly more involved than the first example, but still pretty darn simple! By the time you were able to get logged into SharePoint Designer and started doing the work, you could have already had this script done with the Data Zoom web part. ;)
Well, I've tried to provide you with a bit of history on NVelocity, and I've shown you a few simple examples of how our SharePoint Data Zoom Web Part can make it really easy for you to create applications in SharePoint. These examples have been extremely simple. There are more in depth examples available on the community site (link below). I'll wrap up with a few more notes and links you may find useful as next steps.

• SharePoint Data Zoom Web Part home page
  
  - Get more info and download the bits.
• Help documentation
  
  - Online documentation.
• Community site
  
  - Shared scripts library.
• Support forums
  
  - Ask questions, get answers.

Even further reading...

• NVelocity Syntax Highlighting in Visual Studio 2008 and Visual studio 2005


• Ostensibly to prove Scott Guthrie wrong, Chad Myers espouses NVelocity as an alternative view engine for ASP.NET

SharePoint Data Zoom Web Part Released

The SharePoint Data Zoom Web Part is a free tool which allows SharePoint users to easily build dynamic, data-driven content on any page. Data from SharePoint Sites, SharePoint Lists and virtually any other source can be aggregated and formatted with ease.

Using the Data Zoom Web Part, your SharePoint pages can perform powerful, flexible queries on a variety of data sources using simple, familiar syntax that's easy to write and understand. You'll be able to create robust, value-added SharePoint applications in a fraction of the time, without the need for .NET or XSLT programming.

In our experience, several SharePoint-based applications that would have normally taken a .NET development team a few weeks or more to create by contrast took only a few days with the SharePoint Data Zoom Web Part.

We are starting to Tweet!

We now have an account for our company, SharePoint Solutions, on Twitter. You can catch up with us on Twitter at @SharePointSol

SharePoint Data Zoom Web Part brings NVelocity, MVC to SharePoint

In the coming days, SharePoint Solutions will be releasing our new SharePoint Data Zoom Web Part. With just about all the effort of falling off a truck, this new web part will allow you to pull data from nearly any data source and integrate it directly inline with your SharePoint content. This is made possible with the help of a powerful template engine called NVelocity, but more on that later. (Note: NVelocity is a port of the Apache Velocity template engine to .NET. To find out more about template engines and template languages, start with this article on Wikipedia.)
To determine if the Data Zoom Web Part is right for you, take a look at the following snippet and ask yourself, "would I like to create data-driven web parts literally this easily"?

<p>Hello $customer.Name!</p>
<table>
#foreach( $widget in $widgetsOnSpecial )
#if ( $customer.hasPurchased($widget) )
<tr>
<td>
$lob.getPromo( $widget )
</td>
</tr>
#end
#end
</table>

If you answered "yes", (or "yeah, dude" for you left-coasters) then you're probably ready to take a ride on the Data Zoom express.
Did I mention we're giving it away for free?
The SharePoint Data Zoom Web Part is the brainchild SharePoint Solutions' software production manager Jeremy Luerkens. After using the NVelocity template engine in another platform, Jeremy felt that the SharePoint world just had to get some of that too. NVelocity is a template engine that allows you to manage your web content according to the Model-View-Controller (MVC) model. With MVC, web page designers can focus solely on creating a well-designed site, and programmers can focus solely on writing quality, robust code to support it.
Out-of-the-box, the SharePoint Data Zoom Web Part will include access to site and cross-site list data within your SharePoint environment. Imagine iterating over list items as easily as in the code listing above. We've included a multitude of helper utilities for accessing, manipulating and formatting data. Everything is accessible from a convenient command menu right within the Data Zoom's source editor. We're also including the SharePoint Data Zoom Extension for Syndication free with the Data Zoom. With this extension, you'll have complete control over fetching and integrating RSS and ATOM feeds into your SharePoint pages. Consider this simple snippet to render a feed:

## Renders an RSS or ATOM feed
##
#foreach($item in $feed.items)
#beforeall
<br/><h2 class="ms-standardheader">$feed.Title.Text</a></h2>
<ul>
#each
<li>
<h3 class="ms-linksectionheader"><a href="$item.Links.get_Item(0).Uri.ToString()">$item.Title.Text</a></h3>
<span class="ms-vb" >$item.PublishDate.ToString()</span>
<blockquote class="ms-vb">$item.Summary.Text</blockquote>
</li>
#afterall
</ul>
#end

I just can't imagine how accessing and integrating data from disparate sources inside and outside SharePoint could be any easier than this, while still maintaining complete control over how and where the data is rendered. For data sources other than SharePoint lists and syndication feeds, we've created several Data Zoom Extensions. In the next few weeks, we'll be releasing extensions for access to a variety of data sources including salesforce.com, Microsoft SQL server and Active Directory. Along with our partners, we'll be creating even more extensions which will allow you to integrate data from just about any source you can find.
Stay tuned for much more on this innovative new web part from SharePoint Solutions.

Expanding the Size of Announcements Web Part

The announcements web part that is displayed on a team site will limit the amount of body text that is displayed. Here's a simple way to expand the size of the displayed announcements web part on a team site while retaining a similar format.
Start with a Team Site and modify an announcement to contain a large amount of text. This example uses an extreme amount of text!











Next, open the page with SharePoint Designer. Click on the announcements web part and you'll notice a List View Options button is displayed in the upper left corner of the web part. Click on Change Layout.






Select the Layout tab and select the layout that is 3^rd or 4^th from the bottom of displayed layouts and click OK.




Click Yes to the Site Definition Page Warning dialog. You are now "un-ghosting" the page from the site definition and a custom version of the page is being stored in the database. Save your work in SharePoint Designer.




Reload the page in your browser and look at the results. Notice the additional fields displayed at the bottom of the announcement. Let's get rid of them.






Go back to SharePoint Designer and click on the List View Options button again but this time select Fields. Highlight the fields you want to remove and click the Remove button and then click OK. Save your work in SharePoint Designer and go back and reload your browser to see the results.






The extra fields are now gone.

Give Blood to your Workflow

Give the gift of life.
What does this have to do with SharePoint workflows? Last week I was teaching our Mission: Automation class where we cover InfoPath and workflows created with SharePoint Designer. One of the things we like to do in these classes is take some ideas from our students on business problems that they are trying to solve using SharePoint workflows and attempt to outline the solution and partially implement it during class (if it doesn't become overly complicated). This particular idea was generated by Janice and here was her problem.
Janice is the blood drive coordinator at her place of business. She wanted to figure out a way to use SharePoint and InfoPath to allow people to register for times to give blood. I thought this sounded like a great example of a scheduling application that many people could find other applications for, so I started down the road of creating the "Blood Drive Scheduling Application" during the class. It uses an InfoPath form that an employee fills out to reserve a time slot for donating blood. In this case, there are two donating stations and each one is scheduled at 15 minute intervals during the day. In other words, for each 15 minute interval during the day, we can schedule a maximum of two people to donate at one time.
If someone changes their mind about the time slot they've reserved, we want to give them a way to make a change. However, we don't want to give them the ability to change the original form…they will simply request a cancellation and submit another form for a new time slot. Some of this has to do with who has security to the different lists that we'll be using in SharePoint to solve this problem.
Now, before we get started let me say that there are a number of ways to solve this problem. I was going for a solution that could be implemented during the class and illustrated some of the features of InfoPath and SPD workflows. This is only one solution. Much more elegant solutions could be implemented!
In this solution we're going to use several lists. Blood Drive Reservations will be a forms library where we'll store the completed InfoPath forms. Departments contains a list of the departments at the company. Time Slots contains a list of all the available time slots during the day when a donation reservation can be made. We'll have a Cancellations list that we can use for someone to request a cancellation of their reservation. Finally, we'll use the built-in Tasks list to assign tasks when a cancellation is requested.
First we'll start out by creating a custom list that has two columns. One is the time for each of the 15 minute time slots during the day that we want to schedule and the other column is for recording how many reservations have been made for the time slot. Here's what the table looks like in datasheet view.


I created all the time slots for 8:00 AM thru 5:00 PM.
Next up is to create the InfoPath form and library in which the completed forms will be stored. The form is pretty simple for our example. Greg suggested we add the department field so there could be some competitive statistics compiled between the different departments. Nothing like a little competition during blood letting!


The four fields defined in our form's data source are DonorName, DonorEmail, DonorDept and TimeSlot.


The DonorName and DonorEmail are populated using default values obtained by calling the GetUserProfileByname method in the web service, UserProfileService, referenced at http://server/_vti_bin/userprofileservice.asmx. This web service will return name/value pairs from the user profile store that is part of SharePoint and normally configured to synchronize with Active Directory. The PreferredName and WorkEmail are used in this example.






The DonorDept field is populated by creating a data connection to a SharePoint list containing departments. Nothing really complicated here.


Now, the time slot field is populated in a rather unique way. The idea here is to filter the available time slots based on the value in Counter field in the Time Slot list. We're going to be updating the Counter field with a workflow whenever a new reservation is submitted. We need to create a view on the field that is filtered to only show time slots when the value of the counter is less than 2. I created a view called AvailableTimeSlots and added the simple filter as shown.


Now we're going to use a trick to populate the DonorTimeSlot field. We're going to create a data source to an XML file and reference the SharePoint URL protocol supported by OWSSVR.DLL. This is documented in the WSS SDK and is referenced as follows. http://server/path/sitename/_vti_bin/owssvr.dll?Cmd=Display&XMLDATA=TRUE&List={ListGUID}&View={ViewGUID}. The exact URL for our example is http://portal.awbikes.local/sitedirectory/bd/_vti_bin/owssvr.dll?Cmd=Display&XMLDATA=TRUE&List={BAA912CA-D4D4-4786-B2B8-B33DA8691CA4}&View={35F16EC8-64E9-4BCE-8C8A-CD3D142AD894}.


The GUIDs for the List and View can be found by selecting the Modify View link in the view selector and decoding the GUIDs in the URL that is displayed.
http://portal.awbikes.local/SiteDirectory/bd/_layouts/ViewEdit.aspx?List=%7BBAA912CA%2DD4D4%2D4786%2DB2B8%2DB33DA8691CA4%7D&View=%7B35F16EC8%2D64E9%2D4BCE%2D8C8A%2DCD3D142AD894%7D&Source=http%253A%252F%252Fportal%252Eawbikes%252Elocal%252FSiteDirectory%252Fbd%252FLists%252FTime%2520Slots%252FAvailableTimeSlots%252Easpx


The List GUID and View GUID are URL encoded, and you can "un-encode" them if you want to (but you don't have to) by replacing %7B with a left curly brace { and %7D with a right curly brace }. %2D can be replaced with hyphens. In the example above, %7BBAA912CA%2DD4D4%2D4786%2DB2B8%2DB33DA8691CA4%7D becomes {BAA912CA-D4D4-4786-B2B8-B33DA8691CA4}.
In the next dialog on the Data Connection Wizard, choose the option to Access the data from the specified location.


Give the data connection a name and make sure you automatically retrieve data when the form is opened and click Finish.


You can see the completed URL n the Summary section. I like the way the URL looks when the GUIDs are un-encoded…just easier on the eyes.
On the list box entries for the DonorTimeSlot field you need to reference this data source, OWSSVR, and select the entries as shown.




This will populate the DonorTimeSlot list with the filtered list from the AvailableTimeSlots view.
When we publish our form we will promote all of our fields so they appear as metadata columns in SharePoint.


Now, on to our first workflow.
The first workflow is fairly simple. When a new form is added we want to increment the value of the counter in the Time Slots list for the time slot selected. If two people select the same time slot, the value will be incremented to 2 and the time slot will no longer show up as an available time slot on the drop-down list in our form (because of the filter we created for our AvailableTimeSlots view). Within this workflow, we can also send a confirmation email to the donor. If we really want to get fancy, we can send a reminder email 24 hours before the scheduled appointment. Here's the workflow in SPD.
First, let calculate the new counter value by retrieving the value currently in the time slot and adding 1. We'll save this calculated value in a variable called IncrementedTimeSlotCounter.


To retrieve the current value of the counter we perform a lookup which reads as
Select Counter from Time Slots where Time Slots:Title equals Blood Drive Reservations:Donor Time Slot.
We are matching up the Title in the Time Slot list (e.g. 8:15 AM) with the time slot selected by the donor on the form from the drop-down list. Then we simply add 1 to it and store it in a variable.




Next we update the value of the counter in the Time Slots list. In this example, we've created another step in the workflow to do this.




Here's the screen shot of selecting the Counter field to update in the Time Slots list.


In the "Find the List Item" section, here's the lookup. Again, we're matching up the Time Slots:Title field with the Current Item:Donor Time Slot field (Current Item being our item we're working on in the Blood Drive Reservations list).


Now let's create a workflow that sends a confirmation email and a reminder email. We'll send the confirmation email right away and pause until early in the morning on February 3^rd and then send a reminder email. We can do this with a new workflow that also starts when the item is created. It is okay to have multiple workflows running. Here's what it looks like (nothing fancy). We can reference the Donor Time Slot in the email by clicking the Add Lookup to Body button.


The second step we'll use the Pause Until Date action and put in a pause with a hard date of February 3^rd and a time of 4 a.m. Just a quick and dirty reminder email.


We're all set on the reservation side. Now, on to the cancellation process. Here's the way the cancellation process will work.
We really don't want end users to be able to delete reservation in the list and we can control that by creating a permission level that is similar to Contribute but without the permissions to edit and delete. We can alter the security settings on the reservation list so that our Visitors have this permission level for the reservation list.


If someone wants to cancel, they can insert an item in the Cancellations list. They can select themselves from a drop-down list of people who have reservations and click OK to create the request. I chose to do it this way so we can get a good match on the Donor Name. There are other ways to handle this, but this is quick and dirty.


Once they create a cancellation request, a task is assigned to Connie via a workflow. In this workflow I Iogged some variables to the workflow history list for debugging purposes and then assigned a task to Janice, er, I mean, Connie using the Collect Data from a User action. Logging information to the history list is a very valuable technique for troubleshooting and validating information in the workflow. I normally use three actions in sequence to do this: Build Dynamic String, Set Workflow Variable and Log to History List.


Tasks are very important to understand in workflows. They are so important they get their own categorization in the Actions selection list.


Collect Data from a User allows you to assign a task and, when that task is edited, a custom form is displayed with fields on it that you define in the workflow. In this case we are going to ask Connie if it is okay to delete the reservation with a Yes/No drop-down. Another workflow, Delete Reservation, was created to start on a change to the Tasks list. It's job is to determine what the response was (Yes or No) and lookup and delete the reservation. One of the reasons this method was chosen was because the workflow runs with the credentials of the person who started it. Connie will have the permissions required to delete the item in the reservations list, while the donor does not. It also allows her to verify that the person has requested to delete their reservation and not somebody else's. Here's what the Collect Data from a User action looks like.










Next we'll take a look at the Delete Reservation workflow. This workflow is created on the Tasks list. It has three steps. In the first step we set some variables that we'll use in the workflow. These are very important because we are looking up the IDs of the Blood Drive Reservation we need to delete as well as the Time Slot we need to decrement so it is again available. The key to these lookups begins with the fact that workflow tasks hold some very important information. The contain a "foreign key" back to the ID of the item in the original list.


The first thing we need is the ID of the reservation we might be deleting. To get this we choose to lookup the ID field from the source Blood Drive Reservations. We are going to find this by first matching the name selected in the Cancellations list with the Donor Name in the Blood Drive Reservations list. To find the correct item in the Cancellations list, we need to reference the Workflow Item ID in the Tasks list (our current list) and match that to the ID of the item in the Cancellations list. It is very important to understand that you have access to the Workflow Item ID in the Tasks list. This can be very confusing if you are new to SharePoint Designer workflows, but with some patience it can be understood without having to be a programmer.


Once we have the ID of the reservation, we can find the ID of the time slot that is referenced on the reservation. We'll use this to update the counter on the time slot. We want to find the ID of the time slot so we match the Donor Time Slot on the Blood Drive Reservations list (e.g. 8:30 AM) with the Title on the Time Slots list. We can find the Donor Time Slot by matching the ID of the Blood Drive Reservation with the ID that we looked up in the previous action and stored in the variable ReservationID.


The next step is just some more logging of messages and variables to the history list for debugging purposes. In this example I'm logging the IDs I looked up to insure that I have the right ones.


The final step is to actually delete the reservation. First we look up the current value of the time slot of the reservation to be deleted and subtract 1 and store the result in a variable called DecrementedTimeSlotCounter. This is easy to do since we have already looked up the value of the ID of the time slot that we need to update in the Set variables step.


We can then update the counter value, again using the ID of the time slot that we previously set in the variable TimeSlotID.


Finally we can delete the reservation by using the ID of the reservation that we previously stored in the variable ReservationID.


I know this has been a long post, but hopefully it helps some folks out there become more familiar with SPD workflows. This solution is far from perfect and there are several other ideas I would probably incorporate, but it provides a good demonstration of creating a scheduling application with workflows. I hope you've enjoyed it and learned at least one thing (always my goal).
I'm on my way to bed so I can get on a plane tomorrow to do some training in San Antonio, Texas…a short flight from Dallas. Y'all take care!
Give the gift of life…donate often!