Creating an automatic project number with OOTB SharePoint

On a recent project for a manufacturing client we had a request to automatically generate a project number for tracking a new product through it's development life cycle. This project number needed to be a unique reference, automatically increment, and be able to be revised should specific information on the project change.

This may get a little inside baseball for a bit, but bear with me to the end and you'll understand why.

Requirements

Each project was being represented using a list record in a SharePoint list with an extensive set of information captured for the tracking of the product development life cycle. Another constraint was the process and data were being built out in SharePoint on Office 365, precluding a number of direct coding options.

In following our OOTB SharePoint approach, we looked at a couple of options for implementation including calculated fields and ultimately workflows to generate the needed project number. The specifics of generating the number were less involved than the strategic process around assessing OOTB capabilities to solve the problem. 

Options

In reviewing the requirements one of the first questions asked was, "does something like this already exist?" By default SharePoint generates an ID column for every record, but it is a fixed format and cannot be modified at any time. Let's parking lot that column for the moment. Since that is the only automatically generated, sequential column we had to look at other options next.  

We considered using a date and time field to generate a unique number, and this was a path under consideration for a time, until we realized how long the resulting number would be. Nix that idea.

Decisions

We circled back to the ID field and looked at ways to put it to use. Since the ID field contained a large portion of the information we needed, we combined it with another column the submitter would select to provide the other part.

Adding to this the workflow necessary to update the project number column (since a calculated column wouldn't do the trick) to trigger when a new record was created or the workflow was manually executed did the trick.

Learnings

What is most important to take away from this is that understanding what is already available within SharePoint and then finding ways to put it to new uses is a highly effective way to minimize the amount of custom development needed. This makes for easier support, migrations, and updates. Knowing the ID field availability and limitations made the decision process simpler and the final result a success.