When I started working with SharePoint in 2003, I used multi-word names for everything–my sites, my libraries and lists, even my column names. It didn’t take me long to realize that spaces wreak havoc on my URLs. Since each space in my name causes a %20 string to appear in my URL, my URLs quickly became long and unwieldy.

Creating a new SharePoint site named Help Desk, for example, results in the URL:

https://splibrarian.sharepoint.com/Help%20Desk/SitePages/Home.aspx

If I create a new document library on that site named Sarah Haase, my new library’s URL lengthens to:

https://splibrarian.sharepoint.com/Help%20Desk/Sarah%20Haase/Forms/AllItems.aspx

And when I add the nested folders Fiscal Year 2013 > Projects > Project X > Design Documents to my document library, my URL extends to:

https://splibrarian.sharepoint.com/Help%20Desk/Sarah%20Haase/Forms/AllItems.aspx?RootFolder=%2FHelp%20Desk%2FSarah%20Haase%2FFiscal%20Year%202013%2FProjects%2FProject%20X%2FDesign%20Documents

You can quickly see how a deep nested folder structure (complete with spaces in your library and folder names) can negatively impact your user’s URL experience. But this problem is easily circumvented. If you create your sites, document libraries and lists using names without spaces (e.g. HelpDesk), you’ll avoid adding %20 strings to your URLs. Once your sites, libraries and lists are created, you can go back and update their names to include spaces. This will add “friendly” spaces back into your site, library and list names without damaging your nice (short) URLs.

But what about column names?

I recently learned that spaces in your column names can also cause difficulties. When you create a new document library or list column, SharePoint automatically sets an “internal name” for the column. This internal name is the ID for your column. You may need to know and reference this internal name as you build out new SharePoint solutions or customize the look and feel of your Content Query Web Parts (CQWPs).

So how do you find out what the internal name is for your columns? Go into your document library settings or list settings page and click on the hyperlink for your column. When the column’s detail page appears, take a look at the URL that appears at the top of the page. Your column’s internal name will appear at the end of the URL after the string Field=

SharePoint bases your column’s internal name off the “friendly name” you give your column when you first create it. If you create a new column named DocumentType, for example, your column’s internal name will be DocumentType.

If you include spaces in the name of your new column, SharePoint adds a string of additional characters to your column’s internal name. As the following screen shot illustrates, a new column named Category Type results in the internal name Category%5Fx0020%5FType

The more words you add to your column’s initial name, the longer your column’s internal name will become. If you name your column:

What is your business justification for this change

Your column’s internal name will be:

What%5Fx0020%5Fis%5Fx0020%5Fyour%5Fx0020%5Fbusiness%5Fx0020%5Fjustification%5Fx0020%5Ffor%5Fx0020%5Fthis%5Fx0020%5Fchange%5Fx003f%5F

Once your column is created and the internal name is set, you cannot change it. Your only option is to delete your initial column and re-create it.

To limit the length and complexity of your internal column names, treat your columns like you treat your document libraries, lists and sites. Keep your column names short and do not include spaces. Once your column is created and your column’s internal name is defined, you can always go back in and edit your column name and add additional words or spaces. This will make your column name more “friendly” without lengthening your column’s internal name.

And think carefully before you repurpose old columns in your lists and libraries. While you may change the name of your column an infinite number of times, the internal name for your column won’t change.

References

I first learned about internal column names during Peter Serzo’s CQWP session at SharePoint Saturday Twin Cities. For more information on the “limitless” CQWP, see Peter’s presentation.

Wes Preston recently published a blog post on internal columns and their impact on the client-side rendering functionality in SharePoint 2013.

This is a common request, particularly if your site has quite a few lists. Rather than bogging your users down with navigating into (and out of) each list, you may want to give your customers a quick and easy way to jump from your site’s landing page into your list forms and then back to your site’s landing page. The steps would look like this:

1. Customer comes to your SharePoint site.
2. Customer sees on your landing page a list of the form(s) that apply to them. They click on a link to go to the form they need.
3. They fill out the form and click Save.
4. They’re automatically returned to your SharePoint site’s landing page.

The first 3 steps are fairly straightforward, but step #4 is interesting. Normally, you are automatically taken to your list’s default view when you fill out and save a new item request. We want to change this default behavior. We don’t want our users to be taken to our list’s default view, because they don’t need to see all our list data. We want them to find their form, fill it out and then return to where they started. Fortunately, there’s a quick way to alter your user’s default path. By creating a custom link to your form and modifying the link’s HTML code, you can force SharePoint to take your end-users back to their starting point once they’ve finished filling out their form.

There are a variety of ways to modify your hyperlinks, including making customizations via SharePoint Designer. This blog post focuses on building these custom hyperlinks with out-of-the-box SharePoint web parts. Since the process differs slightly for MOSS 2007 and SharePoint 2010, I’ve included setup instructions for both platforms.

MOSS 2007 setup

First, you need to obtain the hyperlink for your list’s New Item form. Here are the steps for capturing this URL:

1. Go to your site’s landing page.
2. Click on Site Actions > Edit Page.
3. Click on one of the Add a Web Part buttons.
4. Select your list and click on the Add button. A web part for your list will be added to your site’s landing page. (Don’t worry–we’ll delete this web part in just a minute.)
5. Right-click on the Add new item link that displays in the bottom left-hand corner of your list view web part. When the pop-up menu appears, select Copy Shortcut.
   
6. Now you’re ready to delete this list view web part. Click on your web part’s edit link and select Delete.
   

Now that you have your New Item form’s URL, you’re ready to customize the URL and add it to your site’s default.aspx web part page. (Note that the steps outlined below can be used to add custom hyperlinks to any SharePoint web part page. You are not limited to adding these links to your site’s landing page.)

1. Go to your site’s landing page.
2. Click on Site Actions > Edit Page.
3. Click on one of the Add a Web Part buttons.
4. Scroll down the list of web parts until you find the Content Editor Web Part. Select this web part and click on the Add button to add it to your page.
5. When the web part gets added to your page, it will appear with an open the tool pane hyperlink. Click on the hyperlink to configure this new web part.
6. When the web part pane appears, click on the Source Editor… button.
7. When the text entry box appears, key in the HTML code shown below. Replace the text highlighted in yellow with the URL for your new item form. Replace the text highlighted in blue with the verbiage you want displayed as your link. Leave the text highlighted in pink–this is the magic code that will make your hyperlink return users back to your site’s landing page after they submit their form.
   
8. Click Save to save your changes.

That’s it! Your first HTML link is ready to go. Test it out and validate that it is working as desired.

You may want to pretty up your Content Editor Web Part a little bit (e.g. change the name of the web part and add additional form links), but otherwise you are ready for business. Here’s a picture of my finished page:

And here’s a picture of my final Source Editor code:

Note that I added some additional HTML tagging around my links–just enough to create a bulleted list for my form links. You can add in as much (or as little) HTML tagging as you want.

SharePoint 2010 setup

First, you need to obtain the hyperlink for your list’s New Item form. Here are the steps for capturing this URL:

1. Go to the list you want to create a custom hyperlink for.
2. Right-click on the Add new item hyperlink that appears at the bottom of the list view page. When the pop-up menu appears, select Copy Shortcut.
3. Open a new browser window.
4. Go to the address bar and do a Ctrl+V to paste in your newly copied URL.
5. Press Enter. You will automatically be redirected to your list’s New Item page.
6. Copy the updated URL that appears in your address bar–this is the URL you’ll be using to create your custom hyperlink.

Now that you have your New Item form’s URL, you’re ready to customize the URL and add it to your site’s Home.aspx web part page. (Note that the steps outlined below can be used to add custom hyperlinks to any SharePoint web part page. You are not limited to adding these links to your site’s landing page.)

1. Go to your site’s landing page.
2. Click on Site Actions > Edit Page.
3. Click on the Insert subtab.
4. Click on the More Web Parts icon.
5. Click on Forms, select the HTML Form Web Part and click on the Add button.
6. Once the new HTML Form Web Part is added to your page, click on the chevron for the web part and select Edit Web Part.
7. When the web part pane appears, click on the Source Editor… button.
8. Delete the text that appears in the text entry box.
9. Key in the HTML code shown below. Replace the text highlighted in yellow with the URL for your new item form. Replace the text highlighted in purple with the verbiage you want displayed as your link. Leave the text highlighted in pink–this is the magic code that will make your hyperlink return users back to your site’s landing page after they submit their form.
10. Click Save to save your changes.

That’s it! Your first HTML link is ready to go. Test it out and validate that it is working as desired.

You may want to pretty up your HTML Form Web Part a little bit (e.g. change the name of the web part and add additional form links), but otherwise you are ready for business. Here’s a picture of my finished page:

And here’s a picture of my final Source Editor code:

Note that I added some additional HTML tagging around my links–just enough to create a bulleted list for my form links. You can add in as much (or as little) HTML tagging as you want.

I am a librarian, NOT a developer. But today I built a very cool formula that examines list metadata fields and dynamically applies formulas to calculate project milestone completion dates. Here’s my business scenario:

I have a SharePoint list that is used to track project tasks for my documentation department. The list has a variety of fields, including:

• Project name
• Project manager
• Task type – a Choice field with the following valid values:
  • Design documentation
  • Write documentation
  • Proofread
• Task description
• Technical writer assigned
• Task due date
• Task start date (this is the field I want to auto-calculate)

Project managers will come to this list to enter documentation tasks that need to be completed for upcoming projects. Many of the tasks may be logged early on in the project, but may not need to be started (or completed) until later in the project’s lifecycle. To help ensure that each task is kicked off in a timely manner, the project managers want to automate the calculation of task start dates. When the project managers log each task, they’ll identify the task type and the task due date. They then want SharePoint to look at the task type, deduce how much lead time will be needed to complete the task and automatically specify a task start date.

I’ve built this type of solution before, but have always used custom SharePoint Designer workflows to make my calculations for me. This wasn’t an option in this case, as the project managers wanted to avoid any SharePoint Designer customizations. And while I knew that Calculated columns offer a huge amount of functionality, I was unsure how I (the librarian) was going to figure out how to create the necessary formulas.

I started out reviewing Calculated column formula help guides, including http://msdn.microsoft.com/en-us/library/bb862071.aspx. From there I started experimenting with a basic formula that would look at the Task type field. When it found a list item whose Task type field was set to Design documentation, it would take the value in the Task due date field, subtract 52 days and report the results. Here’s this starter formula:

=IF([Task type]=”Design documentation”,[Task due date]-52)

And here’s how my calculated Task start date column looks, now that I’ve inserted this formula:

Let’s check out how this new field works. When you look at my list below, note that the top list item has a Task type of Design documentation. And just as we wanted, this task’s start date is automatically set to 52 days prior to the recorded task due date. Perfect!

There is a problem, however. All of my list rows that have a Task type not equal to Design documentation have a task start date value of 0. This is clearly not what we were hoping for. So I went back to the drawing board to create a formula that would work for binary fields (aka fields that have 2 possible valid values). Here’s the result:

=IF([Task type]=”Design documentation”,[Task due date]-52,[Task due date]-10)

Notice that this field includes 2 calculations–one for subtracting 52 days and another for subtracting 10 days. This formula will examine each list item’s Task type field. If it finds a value of Design documentation, it will subtract 52 days from the Task due date. If it finds any other value in the Task type field, it will subtract 10 days from the Task due date.

This is a bit better than our first option, but it won’t scale if our field has more than two options. I also don’t like how non-specific this formula is. It treats every value other than Design documentation identically.

After some trial and error, I evolved the formula again, this time modifying it so I could explicitly call out each possible field value and the corresponding date calculation to be made:

=IF([Task type]=”Design documentation”,[Task due date]-52,IF([Task type]=”Write documentation”,[Task due date]-40,IF([Task type]=”Proofread”,[Task due date]-10))

This new formula has 3 clauses, each of which specify a Task type value and the corresponding number of days that should be subtracted from the Task due date to determine the Task start date. Here are each of the clauses, broken out into different lines for easier viewing:

• IF([Task type]=”Design documentation”,[Task due date]-52,
• IF([Task type]=”Write documentation”,[Task due date]-40,
• IF([Task type]=”Proofread”,[Task due date]-10))

Here’s how my calculated Task start date column looks, now that I’ve inserted this formula:

And here’s the final result:

Nice! Now my Task start date field automatically reads the type of project task and determines the date when the task should be started. I should also mention that this solution works for both SharePoint 2010 and MOSS 2007.