In “You CAN Count On It (Part 1)“, I showed how you can keep a counter of items in a list and use that counter to compose a field value. It was a simple example, done in MOSS 2007. The actual problem I encountered in the real world was somewhat more complex, and I am going to walk you through its solution, this time in SharePoint 2010.
Detailed Problem Statement
The client wanted a list of projects, with typical project-related info including who was assigned to each, the status (in progress, on hold, complete, cancelled, etc.), the start and end date (estimated if not yet complete), and so on. They also wanted each project in the list to have a particular type (such as sales, engineering, development, and so forth) as well as a location (their actual values aren’t important – for this example, we’ll use “Central”, “Southern”, “Eastern”, “Western” and “Northern”). For reasons only they know, they wanted the “Project Identifier” to be composed of the year the project was intitiated, followed by a 3-character abreviation representing the type (SLS for Sales, ENG for Engineering, etc.), 3 characters representing the region (we’ll use “CEN” for Central, “SOU” for Southern, and so on), and finally a count of projects of that type in that region in that year. So the first Sales project in Northern Region for 2012 would get a Project ID of “12SLSNOR01”, the second sales project in 2012 would be “12SLSNOR02”, and so on. But if the next project was in a different region, or of a different type, the counter needed to start over, for example “12ENGNOR01” or “12SLSCEN01”.
Also, because the company was going through a major corporate change, an IT Systems freeze was in effect, and although we could create anything we wanted using the SharePoint UI, nothing could be installed on the server, so a no-code solution to this problem had to be found.
As I mention in my earlier post, an exhaustive search of the internet on how to to count items in a SharePoint list consistantly led to the same two answers: some said it couldn’t be done, while others suggested writing a custom workflow in Visual Studio to achieve the task. Neither of these answers was acceptable to the client at the time. The solution I came up with involves keeping track of how many projects of each type and region you already have in the current year, using another SharePoint list. It builds on the idea presented in “You CAN Count On It (Part 1)“, but for this post, I am going to build the solution in SharePoint 2010 (although it could just as easily be built in MOSS 2007 with few changes).
First: Create the lists
We are going to need 4 lists for our solution: one to hold the project types and their abbreviations, one to hold the regions and their abbreviations, one for the projects themselves, and one to keep track of the number of items that exist in the Projects list of each type and region in a particular year.
For the Project Type list, create a new custom list called ProjectType, and add a 3-character text column to it called “Abbreviation” (leave the built in “Title” column, but make it unique). Similarly, for the Project Locations, we will build a new custom list called Regions, and add a 3-character text column to it, also called “Abbreviation”, and also make the Title column unique. You will not need attachments for either of these lists, so feel free to disable them. You probably also want to make the Abbreviations columns mandatory and enforce unique values on them. Your end results (with data populated in it) will look something like this:
Next, create the Projects list. Add columns of the appropriate type for each of the required data fields (Date Time for “Estimated Start Date” & “Actual Start Date”, Person Or Group for “Assigned To”, Choice for “Status”, and so on). I also changed the built-in Title column to “Project Name”, and made it enforce unique values. For the Project Type and Region columns, create “Lookup (information already on this site)” columns bound to the Title column of the ProjectType and Regions lists respectively. You do not need to add columns to show any additional information (but you can if you want to), however you do need to make these columns mandatory. I also recommend that you enforce the “Restrict Delete” relationship behavior, so in the future your Project Types and Regions don’t become orphaned. Finally, you are going to need a Text column of length 10 to hold the ProjectId field, which we will populate using a workflow we are going to build in SharePoint designer. The list’s design will look something like this when you are done:
Finally, we are going to need a list to keep track of what ProjectId’s we have already used, as folows:
- Create a new Custom List called “ProjectsCounter”. Set “Display this list on the Quick Launch?” to No. Alternately, you could modify the ListCounts created in the first post of this series to serve a dual purpose of counting cutomers in the customer list and projects in the project list. I’ll leave doing that as an exercise for the reader.
- Navigate to the Settings page for your newly created “ProjectsCounter” list, and edit the “Title” column, renaming it “ProjectPrefix”, and setting it to Enforce Unique Values.
- Create a new required column called “ItemCount”, of type Number with zero decimal places, a minimum value of 0, and a default value of 0, and also setting its Enforce Unique Values property to yes.
- Start SharePoint Designer, and open the site in which your lists exist. You may optionally change the properties of the ProjectsCounter list to Hide it from Browsers
Second: Build the Workflow
You are now ready to create a workflow in SharePoint Designer that will set the “ProjectId” as items are added to your “Projects” list. Start by creating a new list workflow in SharePoint Designer, and bind it to the Projects list. I called my workflow “Set Project Id” and gave the following description: “Sets the Project Id based on the Year, Project Type and Region.”. You will want to set your workflow to start automatically when an item is created. For now, you may also want to be able to run the workflow manually (useful during testing and debugging). You might also want to allow the workflow to be run manually later, if someone wants to delete a list item and you need to re-use the Project ID. Deleting and re-numbering list items will be discussed in a subsequent post. If deletes aren’t required, or you aren’t sure, its probably safest to turn off the ability to run the workflow manually when you are done building it.
The logic we are going to use to set the Project Id goes something like this:
- Figure out the current year, and convert it to a 2-digit format, and save that value to a variable called “yr”.
- Look up the ProjectType Abbreviation in the ProjectType List for the Project Type selected in the project, and save that value to a variable called “pType”.
- Look up the Region Abbreviation in the Regions List for the Region selected in the project, and save that value to a variable called “region”.
- Concattenate yr, pType and region, and save that value in a variable called “prefix”
- Lookup the ItemCount in the ProjectsCounter list for the row with a value in the ProjectPrefix column that matches what we have in our “prefix” variable and put it in a new variable called “counter”. Note that if you don’t find it, “counter”`will be zero, which is perfect.
- If “counter” is 0, create a row in the ProjectsCounter list for the ProjectPrefix “prefix” with a value of 0. There is no else condition, because if “counter” is anything other than zero, an item with a ProjectPrefix matching our “prefix” variable already exists.
- Increment the counter variable.
- Update the existing ProjectPrefix item to the new value in “counter”.
- Concatenate prefix and counter to get the Project Id we need.
- Write the resulting value into the ProjectId column of the item in the Project list that we are looking at.
Building the workflow for step 1 is pretty straight forward. We know the current date is saved in the built-in “Created” field of the current item, so extract that value as a short date and parse out the last two characters to get the 2-digit year value, as shown below.
Step 2 is also fairly straight forward. Click the fx button in the “Lookup for String” dialog to select the ProjectType in the current Item to match on, resulting in something similar to what is shown below.
When you click OK on the dialog, you will be prompted that the lookup you defined is not guaranteed to return a single value. This is fine. In fact it will return a single value (although SharePoint doesn’t recognize this fact), because we put a unique constraint on the ProjectType list’s Title and Abbreviation columns, and we forced the Project Type in the Project list to select only from this list (so click “Yes” to that prompt).
Repeat the process for step 3 to get the Region’s abbreviation from the Regions list, with the following result:
For step 4, concatenate the year, project type abreviation and region abbreviation to get the prefix for the project Id. Click the elipses (three dots) button in the “Set Workflow Variable” action to open the “String Builder” dialog. Use the “Add or Change Lookup” button at the bottom of the dialog to select fields to include. You can optionally include literal characters such as spaces, hyphens, the ampersand (&) character, etc. (I did in the screenshot below, but in truth the solution does not call for them in this instance. They are included in the picture for information only. My actual value in the String Builder window was [%variable: yr%][%variable: pType%][%variable: region%] with no spaces between the variable references.)
In step 5, we use the “Set Workflow Variable” action to set a new variable called counter to the value of the ItemCount field in the ProjectsCounter list where the ProjectPrefix matches the “prefix” workflow variable we constructed at step 4.
For step 6, test the returned value of “counter”. If it is zero, its because the ProjectCounter list was found to not contain any items with a ProjectPrefix that matches the “prefix” we have constructed, which means there are no projects with that type and region created yet this year. So we need to create a new list item in ProjectsCounter, and set the ProjectPrefix equal to the value in the “prefix” variable and the ItemCount to the value in the “counter” variable to record this fact.
Next, increment the counter in step 7 to reflect the fact that we have added a new project to the Projects list with a particular type and and region value this year.
Step 8: Now we should write the revised “counter” value back into the ProjectsCounter list. Use an “Update List Item” action, and fill in the values as shown below.
Again, you will have to click “Yes” when prompted about the fact that there might not be a unique match. We know there should be.
Step 9 involves concattenating the prefix with the counter. In my case, the users wanted to always express the counter portion as a 2-digit number, so I check if the value in “counter” is less than 10, and if so, I stuff a zero into the string.
The last thing to do is to write that projectId back to the ProjectId field in the current item in step 10.
And there you have it. Save your workflow, check it for errors, and if there are none found, publish it to SharePoint. Some testing and tweaking may be required, which you can do by adding a dummy project and running the workflow manually. You can also manually edit the value(s) in the ProjectsCounter list and re-run the same workflow on the same dummy project a few times to check all the different paths through the workflow. During development, I sometimes wrote the value of one of the variables into the ProjectId field as a way of checking the progress. You can also add any number of “Log to History List” steps to output some tracing info to help you fine tune your process, but in a nut shell, I hope this post has helped you see that you although you can’t easily count items in a SharePoint list dynamically at run time, you can use a list and a workflow to keep track how many items you have so far in another list that match a particular pattern, and you can use that same data on insertion of new items.
I hope you found this post useful. As mentioned at the end of my first post, you may want to prevent users from editing the ProjectId field now that you have filled its value in via the “Set Project Id” workflow. See my second post for info on how to do that.