Daryl Rasmussen's Not-so-random Thoughts about SharePoint Here in my world

Archive for the ‘Lists’ Category

Tweaking the built-in Survey List

My client wanted to be able to create their own survey that respondants could fill out on-line, and the built-in survey list in SharePoint seemed a likely candidate for doing this (though we did briefly toy with InfoPath as an option as well).

There were a few things about that built-in survey that needed to be tweaked.  Here’s some links that proved useful:

Create List Instance without List Definition

This worked (mostly):


But:  in SP Here at my client’s office, I had to muck about with the Target location (step 6) for the Schema.xml file.   I ended up setting it to the name of the visual studio project, not the name of the list contained there-in.  Also in step 6, file I edited was SharePointProjectItem.spdata, not SharePointItem.data.

Finally, I had to rename the .stp to a .cab not a .zip before I could open the manifest.

In case the link above ever breaks (and also so I have the instructions handy for myself in future), here’s the content of it, replicated for posterity.  Credit is hereby given to the original author, Saurabh Khatri, for a great time saving idea.

Assumtions: I am assuming that we have already created SharePoint Project in Visual Studio 2010.

Preparing Solution Structure

1. In your visual studio instance, Right Click on your sharepoint project and click on Add > New Item.
2. From the Wizard, choose the SharePoint List Instance.
3. a) Give some name your List Instance(Display Name), I will give this ‘MyNewCustomList’
b) Choose a List Template, You can choose any List Template, and choose a List Instance, Let me choose Custom List to keep it simple.
c) Give List a URL, “Lists\MyNewCustomList”
d) Click ok to close the wizard.
4. After step 3, we will be having a SharePointItem  ‘MyNewCustomList’ of type List Instance with a element.xml file, instantiating it from TemplateType=100, that will create a custom list with a Title Column in it. But we wanted to add the fields to this custom schema.(In SharePoint 2010 we can create a List Instance without creating a ListTemplate by specifying CustomSchema property for ListInstance. http://msdn.microsoft.com/en-us/library/ms476062.aspx

<ListInstance Title=”MyNewCustomList” OnQuickLaunch=”TRUE” TemplateType=”100″ Url=”Lists/MyNewCustomList” Description=”My List Instance” CustomSchema=”MyNewCustomList\Schema.xml” />

5. Now Lets Add a Schema.xml File to your SharePointItem.
6. Also include this file into your SharePointItem.data file.
This is how we do it. Click on the your ‘MyNewCustomList’ in Solution Explorer in Visual Studio. Right click Open Folder in Windows Explorer. Open SharePointItem.Data in notepad

<ProjectItemFile Source=”Schema.xml” Target=”MyNewCustomList\” Type=”ElementFile” />

We are done with Solution Preparation steps.

We will now create a Custom List in SharePoint with ”MyNewCustomList”. Go to List Settings and Add the columns, as per the requirement. After doing with all changes whether it is a addition of List Column, Creating a View, addition of some content Type etc.

1. Save this list as Template. Go to Template Gallery, and Download your list template. This file will be a .stp file.\
2. Change the File Extenstion to .zip.
3. Open the zip file, it will contain a manifest.xml
4. Open Manifest.xml file in some nice editor like notepad++.
5. Carefully, Locate node “<List>” in this xml. Copy this entire section of <List>…</List> and now paste it in your schema.xml file we created in above steps.

Few Final Modifications and we are done in Schema.xml file.

1. Remove the name attribute containing List GUID of your previous List.

<List Name=”SomeGUid” …> remove this Name attribute, we don’t need this in our schema

2.Replace the following  nodes <View>

<View BaseViewID=”1″ Type=”HTML” Level=”1″ ContentTypeID=”0x” WebPartZoneID=”Main” OrderedView=”TRUE” DisplayName=”All Links” DefaultView=”TRUE” MobileView=”TRUE” MobileDefaultView=”TRUE” SetupPath=”pages\viewpage.aspx” ImageUrl=”/_layouts/images/links.png” Url=”AllItems.aspx”>

Also replace the Forms Node with the below one.


<Form Type=”DisplayForm” Url=”DispForm.aspx” SetupPath=”pages\form.aspx” WebPartZoneID=”Main” />
<Form Type=”EditForm” Url=”EditForm.aspx” SetupPath=”pages\form.aspx” WebPartZoneID=”Main” />
<Form Type=”NewForm” Url=”NewForm.aspx” SetupPath=”pages\form.aspx” WebPartZoneID=”Main” />


Great we are done, Now we can include this ListInstance in a feature and create a package. Activating that feature will create a ListInstance.

The first client I used this technique at was on SharePoint 2010.  It worked as well for me in SharePoint 2013 at the next client as well.

Why the “Next” Button Doesn’t Work for Me in SharePoint 2010 Surveys

Recently I was helping a client put together a survey in SharePoint 2010, showing them all the various types of questions, and things you can do with them.  They were having a hard time visualizing it, so I ended up building their survey for them so they could see the overall effects in their desired question set.  About 65 questions in all, and to my dismay the “Next” button (which shows up at the top and bottom of the form if you have either a Page Separator field or if you implement branching logic in your questions) wasn’t working.

The first “page” of the survey would load, but when the “Next” button was clicked, that page would just re-load.  It would NOT move on to the next “page” (after the Page Separator or branch).  I searched everywhere on the internet for a possible reason.  Nada.  Nothing.  I can’t believe I’m the only person who ever encountered this.  And I certainly can’t show it to the client in this state.  WTF?

I thought maybe the client had re-ordered the questions in the branching logic, resulting in some kind of circular reference.  I painstakingly went through every question (hint – click the “Change the order of the questions” link from the Survey Settings page to see a summary of what is branching where).  No luck.  Everything seemed fine.

I then thought perhaps the use of special characters like quotes and apostrophes in the question title were mucking things up.  So I removed all of them (Changing questions like “Please enter any comments regarding the president’s address” to something like “Please enter any comments regarding the presidential address”).  No joy.  Still it would not leave page 1.

Then I thought maybe my survey list was corrupt.  Hey, lets face it.  Sometimes that happens with SharePoint.

So I rebuilt it (all 65 questions of it!) from scratch, stopping after every page separator question was added, and after every branch section was set up to test the new survey.  63 questions in, and everything is looking good.

The answer came when I added my 64th question (which was a plain text field for people to enter their phone number if they wanted to be contacted regarding their submission).  The fly in the ointment was that it was using the column validation capabilities of SharePoint to ensure the phone number was entered in a standard format.

The field was called “Optional – Phone” and had the following Column Validation formula:

=AND(LEN([Optional – Phone])=14,IF(ISERROR(FIND(“(“,[Optional – Phone],1)),FALSE,(FIND(“(“,[Optional – Phone])=1)),IF(ISERROR(FIND(“)”,[Optional – Phone],5)),FALSE,(FIND(“)”,[Optional – Phone],5)=5)),IF(ISERROR(FIND(” “,[Optional – Phone],6)),FALSE,(FIND(” “,[Optional – Phone],6)=6)),IF(ISERROR(FIND(“-“,[Optional – Phone],10)),FALSE,(FIND(“-“,[Optional – Phone],10)=10)),IF(ISERROR(1*CONCATENATE(MID([Optional – Phone],2,3),MID([Optional – Phone],7,3),MID([Optional – Phone],11,4))),FALSE,AND(1*CONCATENATE(MID([Optional – Phone],2,3),MID([Optional – Phone],7,3),MID([Optional – Phone],11,4))>1000000000,1*MID([Optional – Phone],2,3)<>911,1*MID([Optional – Phone],7,3)<>911,1*MID([Optional – Phone],7,3)<>555)))

It also had the following User Message:

Please enter the phone number in the format (###) ###-####

Do you see the problem?  I didn’t at first, but here’s what I now believe:

When the user is finished answering the questions on Page 1 and clicks next, the above validation rule fires, and fails.  The “Optional – Phone” field is on a different page that the user has not gotten to yet, so of course they haven’t filled the “Optional – Phone” field in yet.  And even though the field is not mandatory, the first part of the validation rule says that the length must be 14 characters.

The length at this point is still zero.  The User Message is probably being displayed under the “Optional – Phone” field, but since the field isn’t visible on the current page, the user gets no feedback and the “Next” button just reloads the current page.

Of course this is just a theory, because I can’t find anything in Microsoft’s documentation to say that this is what’s happening, however when I change the Column Validation formula to allow either zero or 14-character length strings, the problem goes away, so it seems a valid assumption.

For those who are interested, here’s the corrected formula:

=OR(LEN([Optional – Phone])=0, AND(LEN([Optional – Phone])=14,IF(ISERROR(FIND(“(“,[Optional – Phone],1)),FALSE,(FIND(“(“,[Optional – Phone])=1)),IF(ISERROR(FIND(“)”,[Optional – Phone],5)),FALSE,(FIND(“)”,[Optional – Phone],5)=5)),IF(ISERROR(FIND(” “,[Optional – Phone],6)),FALSE,(FIND(” “,[Optional – Phone],6)=6)),IF(ISERROR(FIND(“-“,[Optional – Phone],10)),FALSE,(FIND(“-“,[Optional – Phone],10)=10)),IF(ISERROR(1*CONCATENATE(MID([Optional – Phone],2,3),MID([Optional – Phone],7,3),MID([Optional – Phone],11,4))),FALSE,AND(1*CONCATENATE(MID([Optional – Phone],2,3),MID([Optional – Phone],7,3),MID([Optional – Phone],11,4))>1000000000,1*MID([Optional – Phone],2,3)<>911,1*MID([Optional – Phone],7,3)<>911,1*MID([Optional – Phone],7,3)<>555))))

After many days of cursing and frustration, the Survey is working again.

The moral of this story is  “Be careful with Column Validation in Survey Lists”.

That’s SP Here.  I would bet a case of doughnuts that the same is true in MOSS 2007, SP 2013, and O365.

You CAN Count On It (Part 3)


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:

ProjectType List

ProjectType List

Regions List

Regions List

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:

Projects List

Projects List

Finally, we are going to need a list to keep track of what ProjectId’s we have already used, as folows:

    1. 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.
    2. 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.
    3. 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.
    4. 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:

  1. Figure out the current year, and convert it to a 2-digit format, and save that value to a variable called “yr”.
  2. 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”.
  3. 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”.
  4. Concattenate yr, pType and region, and save that value in a variable called “prefix”
  5. 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.
  6. 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.
  7. Increment the counter variable.
  8. Update the existing ProjectPrefix item to the new value in “counter”.
  9. Concatenate prefix and counter to get the Project Id we need.
  10. 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.

Workflow Step 1

Workflow Step 1

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.

Get Project Type Abbreviation

Get Project Type Abbreviation

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:

Get Region Abbreviation

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.)

Determine Prefix

Determine Prefix

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.

Find count of projects for a given prefix

Find count of projects for a given prefix

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.

Add ProjectsCounter item

Add ProjectsCounter item

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.

Increment the counter

Increment the counter

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.

write counter back to ProjectsCounter list

write counter back to ProjectsCounter list

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.

Build ProjectId out of prefix and counter

The last thing to do is to write that projectId back to the ProjectId field in the current item in step 10.

Update ProjectId in Projects

Update ProjectId in Projects

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.

You CAN Count On It (Part 2)

In my previous post, I discussed how to use a SP-Designer workflow to build a simple counter for items in a list.  At the end of it, I mentioned that once you have a field created that contains the auto-generated counter, you might want to hide that field from end users on insert (since it will be generated by the workflow), and disable it on update (since you don’t want your business clients mucking with your numbering scheme).

I really like the OfficeToolbox.SharePoint.Lists v1.0 (Custom Forms) tool for exactly that purpose in MOSS 2007 / WSS 3.0.  Once you have downloaded and installed it per Sharad’s instructions, follow these steps to hide/disable your new “CustomerNumber” column:

  1. Navigate to the Settings page for your Customers list
  2. Click the (newly added) Form Settings link
  3. Configure the CustomerNumber column to be hidden on the New form, to be shown on the Display form, and to be shown as a read-only label in the Edit Form, as shown below

Form Settings for CustomerNumber
Click OK to save your changes, and then check out the behavior on your Customer List’s Add, View and Edit pages.

I’ve also downloaded and and attempted to install this tool in SP 2010, including re-naming the “Form Settings” to “Field Settings” as described here.  I was not successful.  I encountered a correlation error when I tried to deploy the feature.  It may work for you, but in the mean time I will see if I can download the code from CodePlex and figure out how to make it to work with SP 2010.

Up next:  a bit more complicated real world counting example.


You CAN Count On It (Part 1)

Several years ago, I needed to create a column in a SharePoint list that included a count of the items in the list – much like an auto-number field. Much searching on the internet led me over and over to the same two answers:

  • “use the ID column of the list” as part of a calculated value, or
  • “there is no way to count columns in SharePoint without coding a custom workflow”.

The first option, using the ID column, is not effective. As items are added and removed from a list, the ID column quickly develops “gaps” in the sequences, and can not be reliably used to determine how many items are in the list.

The second option, writing a custom workflow, was not an option at the time for that particular client.  I have decided to make how I solved this problem, and how it could be solved today the subject of my first set of posts.

After many hours of surfing the net looking unsuccessfully for an answer, it finally occured to me that if I knew how many items there were already, I wouldn’t have to count them. And, when a list is new, you know for a fact that it has zero items in it. When you add a row to the list, increment the “counter”. When you delete one, decrement it.

The following procedure (and screen shots) are for MOSS 2007, but a similar process could easily be followed in SP 2010.

  1. Create a new Custom List called “ListCounts”. Set “Display this list on the Quick Launch?” to No.
  2. Navigate to the Settings page for your newly created “ListCounts” list, and edit the “Title” column, renaming it “ListName”
  3. 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
  4. In the list that you want to have a “counter” column for, add a new column of type “Number” of type Number with “Number of Decimal Places” set ot 0. Set the formula to “0” (without the quotes). For this example, I named this column “CustomerNumber” in the list “Customers”.
  5. Go back to your “ListCounts” list, and add a new item. In the “ListName” column, enter the name of the list you want to have a counter in (“Customers” in my example), and a value of 0 in the “ItemCount” column.
  6. Start SharePoint Designer, and open the site in which your lists exist. You may optionally change the properties of the ListCounts list to Hide it from Browsers

You are now ready to create a workflow that will set the “CustomerNumber” as items are added & removed from your “Customers” list. Start by creating a new workflow in SharePoint Designer.
Create a new workflow...
Give your workflow a meaningful name.  Select the list (Customers) it should operate on, and set it to run both on demand and on insert of new items.
Name your workflow
Click Next.  On the screen that appers, give step 1 a meaningful name.  Click the Actions button, and add a “Set Workflow Variable” action.
Step 1
Click the “Workflow Variable” link, and select “Create a new variable…” of type Number called “Counter”.
Set Workflow Variable
Click the “” link. Click the fx button, and fill in the form as shown below to retrieve the current count of customers from the ItemCount field of the ListCounts list.
Get ListCounts.ItemCount

Click OK.  You will be prompted with a warning that the lookup may not return a unique value.  This is fine.  Click Yes.  Click the link (top right) to add a new Workflow Step.  In the screen that appears, give the step a meaningful name and click the Actions button to Add a “Do Calculation” step.
Add Do Calculation Step

Add 1 to the current value of the “Counter” variable, and save the result back to the “Counter” variable.
Increment the counter
Click the link (top right) to add a new Workflow Step.

Counter Incremented

In the screen that appears, give the step a meaningful name and click the Actions button to Add a “Set Field to Value” step. Save the newly calculated “Counter” variable’s value to the “CustomerNumber” field in the current item.  Click “Add workflow step” one last time.
Set Field to Value
Add an “Update item in this list” action. Click the “this list” link, and use the dialog that appears to set the ItemCount field to the value in the Counter variable (click the Add… button), for the row with a “ListName” of “Customers”.

Update ListCounts

Click OK to close the dialog box.  Click Yes to the warning that this might not return a unique value.

Click the Variables button, and remove all but your Counter variable.

Click the “Check Workflow” button to validate the steps entered.  Fix any errors encountered (there should be none if you followed these instructions).  Click Finish to save the workflow.

If your list already had items in it, you will need to run the workflow on each item in the list (one after the other) manually to assign values to CustomerNumber fields in the existing list items.  Once all existing items have a value, you can edit your workflow if desired to remove the ability to run the workflow manually.  If you have LOTS of records, you may want to change to “Edit in Datasheet” view, and just manually enter the numbers yourself.  If you do that, be sure to edit the ItemCount in the ListCounters list to match the last row entered manually.

At this point we have an “aut-number” field in the Customers list that is incremented by 1 for each new list item.  Admittedly, this does not buy us much when compared to using the built-in ID column of the list.  But we could have used any increment we wanted (for example, adding 10 for each new item).  We also have a list called ListCounters, with a row for “Customers” containing the count of items in the Customers list.  If you decide to increment by ten, you may want to add another column to ListCounters to keep track of the next index value to be used (or amend the formula in step 2 of your workflow to work it out at run time).

In a later post I’ll build on this basic idea to make a much more complex set of automatically generated identifiers in a list (which is what I actually needed to do originally when this process was first conceived).

Up next you may want to hide or disable the CustomerNumber field in the insert and edit forms for the Customers list so your users don’t inadvertently muck with it.

Third in this series:  a more complicated real world example, implented in SP 2010.

Eventually, I plan to explore options to decrement the counter.  Watch for additional posts coming soon…

Tag Cloud