Adding Custom Actions to the Ribbon UI in SharePoint 2010 Using SharePoint Designer 2010

image In my last article, Adding Custom Actions to the List Item Menu in SharePoint 2010 Using SharePoint Designer 2010, We walked through the process of adding custom actions to the List Item Menu using SharePoint Designer 2010, today, we’re going to have a look at the other Custom Action functionality available to us in SharePoint Designer 2010.

This article is going to group the rest of the options within our Custom Actions drop-down in SharePoint Designer 2010 together, as they are all basically doing the same thing, adding an item to the Ribbon UI, just for different forms (View, Edit, New, and Display).

imageFirst, let’s open SharePoint Designer 2010 back up. So, let’s go into our 2010 test site, and click on the Edit Site in SharePoint Designer action off of the Site Actions menu.















Now that we have SharePoint Designer open, click on Lists and Libraries, under the Navigation > Site Objects, area on the left-hand side of your window.







Here is a quick little tip while we are here as well, that is new in SharePoint Designer 2010. If you hover your cursor over Lists and Libraries, as well as any of the other Site Objects navigation options, you will see a thumbtack appear on the right.



If you click on this, it will expand your Lists and Libraries, or any of the other options, below the Site Objects on the left-hand side, allowing you 2007-like left-side navigation navigation between your objects.

Now, on with the show… as I mentioned back towards the start of this article, we’re going to look at the remaining Custom Actions we can build into our lists from SharePoint Designer 2010.

Click on any list that you have on the site. In this example, we will be using a tasks list that I had created for demonstration purposes.









imageNow that we have our Tasks list loaded, we do not want to use the Custom Actions window in the lower-right hand side of our screen. This will automatically create a Custom Action for the List Item Menu if we click on the New… button. No, to create other types of Custom Actions, we need to use the Custom Action menu in the Ribbon UI to do what we are looking to do.

You will however notice, that by clicking here, the Ribbon context at the top of the screen changes from the List Settings ribbon, to the Custom Actions ribbon.


We are going to use the Custom Actions ribbon to create our first of four custom actions for this article. First, we are going to start with the Display Form Ribbon. To start creating one of these, click on the Custom Action button in the ribbon, and select Display Form Ribbon


By doing so, we see the familiar Create Custom Action window pop-up that we saw in my last article on the subject.


For our example, lets fill in a Name, Description, and under the Select Type of Action, we are going to choose Initiate workflow. For this, I just created a simple list-level workflow, which will e-mail the owner of the task, CC’ing the current user, to request them to review and update the task, with a link back to the task (see screenshot below).


Select our workflow from the drop-down next, in this example, our workflow name is Task Review Request.


Next, if we scroll down in our window, we are going to specify a 32×32 image, so that we have a fancy little icon to go with our button. We could sue a 16×16, but, that will be quite small, and since we’re on the ribbon, we want this to stick out a bit. So, I browsed in the layouts folder in the SharePoint root to find an e-mail related icon, and did, at /_layouts/images/centraladmin_systemsettings_email_32x32.png. You could also use the Browse button to find a local image on your computer or network file share to use.


You will also see in the advanced section, that the wizard automatically entered in the Ribbon Location. This location, Ribbon.ListForm.Display.Manage.Controls._children, is great, because, really, were you going to remember that? Here is a listing of what each of these options are:

Form Name Ribbon Location
Display Form Ribbon.ListForm.Display.Manage.Controls._children
Edit Form Ribbon.ListForm.Edit.Actions.Controls._children
New Form Ribbon.ListForm.Edit.Actions.Controls._children
View Form Ribbon.ListItem.Actions.Controls._children


I have also created a blog post, just with this information, available here, which I will reference in later articles, as needed: SharePoint 2010 Custom Actions – Default Form Ribbon Locations

Now, below there, there is the options for Rights mask. This allows you to assign permissions of who can actually see this custom action. If the user does not meet the requirements, which are comma separated values from the SPBasePermissions class enumeration, they do not see the custom action. We will not apply any currently to this item, leaving it for all to see. But, the option is there.

You can choose your own sequence number for this as well. Generally, the best practice is to use anything over 10,000.

Now, once we are set with this, lets click on OK on the Custom Action Wizard, and now lets see this in action! Let’s go back to our list in SharePoint… Let’s use the List Item Menu, and select View Item


We will get a modal dialog window now with the Display Form, that we linked our Custom Action to. As you will see, we now have a new icon in our View Ribbon, which shows our fancy little e-mail icon, as well as the title of the Custom Action:


Clicking on this will then initiate the workflow which we associated with the Custom Action


And once we click Start on the workflow initiation form, the workflow will then start! Very cool stuff.


To be sure it is actually doing its thing, let’s check the workflows for that list item, back from the main list page, by selecting the Workflows option from the List Item Menu.


Once the page loads, you will see we have a completed workflow for our Task Review Request workflow that we created


Now, to finish up this article, we’re going to add the same Custom Action to the other forms on this site as well. So, back in SharePoint Designer 2010, opened to our list, lets create a new Custom Action for each of the other three forms, and see where they show up.

The only change we are going to make however, for each one, is just in the title. We could have it named the same thing for each form, sure, but, I want to show you where these end up in the SharePoint UI, and to do so, I am doing to insert the name of the form into our Custom Action title.

As you can see, when we choose a different ribbon location for our Custom Action, we get a new Ribbon Location automatically populated for us:


Follow the previous steps in the article if you need to to create these additional actions. When finished, we should have four Custom Actions in total assigned to our list, one for each of the form types:


Now, let’s head back to our our SharePoint site and see where these now appear in the UI.

First – let’s have a look at the List View form ribbon – click on the Items tab under the List Tools ribbon image , and you will see a section for Actions. You will also see in here, that our ViewForm Custom Action is available here. What does this allow us to do? Well, using the multiple-item selection functionality in SharePoint 2010, we can run our action against multiple list items!


Well, you would think… but if you attempt to do so, you will get an error, so, only do this on a per-item basis. The functionality is not smart enough to fire up three consecutive workflows by using SharePoint Designer 2010 for each of the items you have selected. It will work fine when going through them one by one.

Next, if we go into the Edit Item view form for one of our tasks


We will see that we have our Custom Action appearing in the Actions area of the form


And the same goes for when we go to create a new Task


However, until the task is created, you will not be able to run the workflow, as until you hit Save on the new item form, your task does not exist as of yet, so, the workflow has nothing to bind to, just something to keep in mind when creating your Custom Actions in SharePoint Designer 2010. If you do try and run your workflow from your Custom Action – you will get the lovely Runtime Error.


I just wanted to show you where this would appear, and that even though the Edit and New Forms use the same Ribbon Location (Ribbon.ListForm.Edit.Actions.Controls._children), they are actually bound to the individual forms themselves.

I hope this article was informative, and helps shed some light on some of the new functionality available in SharePoint 2010, and SharePoint Designer 2010. Please let me know what you think, or leave any questions regarding this material in the comments, and I will answer them as soon as I can.


SharePoint 2010 Custom Actions – Default Form Ribbon Locations

Below is a listing of the default form (View, Edit, New and Display) ribbon locations. When creating Custom Actions in SharePoint, you will need to reference these locations to determine where your Custom Action will be displayed.

Form Name Ribbon Location
Display Form Ribbon.ListForm.Display.Manage.Controls._children
Edit Form Ribbon.ListForm.Edit.Actions.Controls._children
New Form Ribbon.ListForm.Edit.Actions.Controls._children
View Form Ribbon.ListItem.Actions.Controls._children


This is current for the Beta 2 release, and is subject to change with the RTM version of the product.


Adding Custom Actions to the List Item Menu in SharePoint 2010 Using SharePoint Designer 2010

In SharePoint 2010, it is easier than ever to add custom actions that are scoped to a specific list using SharePoint Designer 2010. So today, I am going to walk you through the process.

In a prior post, I showed you how to surface ULS logs using SharePoint Designer 2010, an External Content Type, and an External List. We’re going to use that list as our base for our custom action.

Our phony business case for this custom action is such – We are surfacing our ULS logs into a SharePoint list, and want to collect feedback on specific log entries for later consumption. We need to link to a form elsewhere in the site, which we will pass a reference to the item in question, as a URL.

Note – the List Item Menu refers to the same thing as the Edit Control Block. This is the context menu which is associated with all list items, available in list views and list view web parts.

So, let’s open SharePoint Designer 2010, and navigate to our ULS Logs list, and we’re going to select Custom Action > List Item Menu from the Custom Action button on the ribbon UI


Once we select that link, we are presented with the following form


We’re going to name our custom action Log Entry Comment, and give it a description as well. Now let’s scroll down. You will see that we have 3 different types of actions we can associate with this custom action…


We can

    • Navigate to a Form for this list
    • We can Initiate a Workflow
    • Or, we can Navigate to a URL

We’re going to select Navigate to URL, and enter in our URL, and enter in our bogus URL, and pass a name/value pair of ItemURL={ItemUrl}, which was found by looking into the November 2009 version of the SharePoint 2010 SDK


OH NO!!!! We can’t use it in Beta 2, which is the public beta we are running! Ok, so I guess on the receiving end, we’ll need to fix it up in some other way. So., we’ll just change our URL to pass a few things, and build the URL ourselves.{SiteUrl}/Lists/ULS Logs/DispForm.aspx?ID={ItemId}

there, that should do the trick…

So, set your URL, and then give it a sequence number. This is the number in which it appears in the list. Anything over 10000 is a good practice, so you do not interfere with any other items in the list.


Then click OK, and you now have a custom action, associated with a list item, all without cracking open Visual Studio, deploying a package, etc. etc.

You will now see it on the ULS Logs list dashboard page in SharePoint Designer 2010


So, let’s go check out list… and there we have it, our custom action, associated to the list item menu/edit control block, within our list!


And if we click it, we get an ugly, url encoded version ( Logs/DispForm.aspx?ID=__cb40004300o4200b7983a57-53e7-de11-8ed4-000c29a9d0f1) of: Logs/DispForm.aspx?ID=__cb40004300o4200b7983a57-53e7-de11-8ed4-000c29a9d0f1

Another cool thing, which you may notice, is that ALL list items have a globally unique identifier in SharePoint 2010! YES! No more list item IDs starting with 1, and going up from there.


Right from the Source – Custom Actions in SharePoint 2010

Just wanted to share this with my readers – Andrew May from the SharePoint Developer Documentation Team, posted a great article on the Microsoft SharePoint Developer Documentation Team Blog yesterday, regarding Custom Actions in SharePoint 2010, specifically, adding a tab with custom actions to the Ribbon interface in SharePoint Foundation Server 2010. This is a good read, straight from the source of the documentation folks themselves at Microsoft.

If you are interested in developing Custom Actions in 2010 – this is a great resource: How to Add a Tab to the Ribbon in SharePoint Foundation


Create a Custom Action to Satisfy Your “All People” Needs.


Thanks for the intro Carl! Much obliged! Well, in your SharePoint world, your “Pale Blue Dot” view of all of the people in your site collection is the “All People” view, you know, the User Information List.

Almost two months ago, I wrote an article on how the “All People” link in SharePoint 2010 is, well, it’s gone MIA. It is easy to get to via  link. And, if you’ve got one site collection to manage, well, its as simple as adding a link somewhere, like in a link list within a management site somewhere, or, up in the handy dandy bookmarking feature, in those fancy things all the kids are using these days, “web browsers”… whatever that means…? Anyways. So, you need to get there, but, wouldn’t it be nice and simple to add in a link to say, I don’t know, the Site Settings page? Wow! That’d be cool! Then I can access it with all of the other Users and Permissions links! Right in one place?! WOW!


So, the question becomes, how can we get it there? (HINT: I mentioned it in the title of this article!)

Ok, so I gave it away, shame on me, I spoiled the ending. Boo hoo. Yes, Custom Actions! That’s how we’ll get it there!

So, what to do? Well, not too much actually. The creation of Custom Actions in SharePoint 2010 and with Visual Studio 2010 has become, well, easy. Extremely easy in fact due to the fine folks who created the CKS:DEV project over at Codeplex. Why? Well, because it contains item types with fancy pants wizards to allow you to click a few buttons, and create a custom action project with ease. You really do not even need to be a developer to do this, it’s quite easy, and hey, I provide screenshots and code. Go ahead, do it!

So, let’s get started, shall we? Oh, you need a glass of water first. No problem. I’ll be here waiting for you.

… 15 minutes to get a glass of water? seriously? Did you pump it from the well?

Ok, so, make sure you have VS 2010 installed, as well as CKS:DEV. NO, I am not waiting this time. You lollygagged around with getting a glass of water last time… You had your chance!


First, create a new project in Visual Studio 2010


Then, create an Empty SharePoint Project

Oh, guess what you’re about to witness? Yes, you in the back in the Charlie Brown polo shirt! You’ve got it. The creation of my next codeplex project for Grace-Hunt (yes, I know, it’s been a while!)

And since we do not need to elevate privileges, or any of that fancy stuff required for a server-side deployment, we’re going to create this as a Sandboxed Solution…


Next, once our project is loaded in the Visual Studio IDE, let’s add a new item to the project.


Right click on your project, go down to Add, then select  New Item.

On the next screen you are presented with, make sure you have SharePoint and 2010 selected under Installed Templates.


Select Custom Action, and give it a name (such as UserInfoList). Then click Add.

Now, again, thanks to the fine folks who created CKS:DEV, we have wizards!


On the first screen on the wizard, we have 6 settings we are going to make use of, detail from here for each of these attributes:






Optional Text. Specifies a unique identifier for the custom action. The ID may be a GUID, or it may be a unique term, for example, "HtmlViewer".



Required Text. Specifies the end-user description for this action.



Optional Text. Specifies a longer description for the action that is exposed as a tooltip or sub-description for the action.



Optional Text. Identifies an action group that contains the action, for example, "SiteManagement". If it is contained within a custom action group, the value of the GroupId attribute must equal the group ID of the CustomActionGroup element.

For a list of the default custom action group IDs that are used in Microsoft SharePoint Foundation, see Default Custom Action Locations and IDs.



Optional Text. Specifies the location of this custom action, for example, "Microsoft.SharePoint.SiteSettings".

If the CustomAction element contains a CommandUIExtension child element, the Location must start with "CommandUI.Ribbon". For a list of default locations that are used with the Server ribbon, see Default Server Ribbon Customization Locations.

If the custom action is a menu item or toolbar button, the possible options include EditControlBlock, NewFormToolbar, DisplayFormToolbar, and EditFormToolbar.

If it is contained within a custom action group, the value of the Location attribute must equal the location of the CustomActionGroup element.

For a list of the default custom action locations that are used in SharePoint Foundation, see Default Custom Action Locations and IDs.



Optional Integer. Specifies the ordering priority for actions.



On the next page, we do not actually need to set this option, however, I wanted to, to showcase this functionality. This utilizes the SPBasePermissions class to show whether this can be viewed to the user, based on the permissions they have for this object, in this case, the site collection.


On the last screen, and this is the important part, we need to specify the URL we want to have our CustomAction link to, this is the URLAction element. The ~sitecollection is a Token. More information on what tokens can be used in a URLAction can be found on slide #30 of my Creating Custom Actions in SharePoint presentation.


Now that we’ve finished defining the custom action, we just have a couple of more things to do. Since we do not our feature to be called “Feature1”, right-click on Feature1 in the Solution Explorer, and choose Rename.


Type it in, hit enter, all good.

Next we want to remove Feature 1 from after the title of our feature. Double click on the UserInfoList feature we just renamed, and we get a designer view of our feature (new in VS 2010).


In the Title field, remove Feature 1 after our feature, and add a description. Also, change the scope from Web to Site, which means we will deploy our solution to the site collection. Which also means, this link will appear for all Users and Permissions sections throughout all of the site settings pages within our site collection.


Now for the money! Right click on the project and select Deploy.


Look at the output window to see if we had success or failure…


And now look at your site settings page – there is our new link!

And that’s it! I will have this project published to Codeplex within the next few days, so, please keep an eye out.

Can a Single Custom Action Work Across All List Types?

A good friend of mine, Mark Rackley, posed a question to me yesterday…

Can I create one Custom Action that will work on all list types or do I have to create a separate custom action for each list type?

Which was a great question, and one that throughout all of the times I have spoken at various events and user groups on Custom Actions, I had never heard asked. So, I thought I would post a blog on this, and answer the question for others as well. Thanks for the ? (“question, Mark”)

Well, why don’t we see what we can do – I’ll take you through the trial and error process, to see if we can make this work.

So, let’s fire up Visual Studio, and get started, and let’s create a new blank WSP Builder Project (as I know Mark is a big fan of STSDEV)


Lets build out our folder structure, and add in our feature.xml file, as well as our element manifest


In our Feature file, let’s scope this out to the Site Collection, and fill in some of the other details…

   1: <?xml version="1.0" encoding="utf-8" ?>
   2: <Feature xmlns="" 
   3:          Id="{842E1000-139E-4e3e-A747-F6E01B2A5AAE}" 
   4:          Title="MarksCustomAction" 
   5:          Description="Mark's Custom Action" 
   6:          Scope="Site" 
   7:          Version="" 
   8:          Hidden="false" 
   9:          ImageUrl="GraceHunt\Grace-Hunt.gif">
  10:  <ElementManifests>
  11:    <ElementManifest Location="manifest.xml" />
  12:  </ElementManifests>
  13: </Feature>

Now, to populate our ElementManifest, which will contain our CustomAction Element, let’s refer to the CustomAction Element section of the Windows SharePoint Services 3.0 SDK.

   1: <?xml version="1.0" encoding="utf-8" ?>
   2: <Elements xmlns="">
   3:   <CustomAction
   4:       Id="MarksCustomAction"
   5:       Location="EditControlBlock"
   6:       Title="Grace-Hunt Website"
   7:       RegistrationType="List"
   8:       Sequence="12345">
   9:     <UrlAction Url="" />
  10:   </CustomAction>
  11: </Elements>

Now, we know, especially if you’ve been to any of my sessions on Custom Actions, that the only thing you REALLY need in here is the Title attribute, but, we’ll add an Id, Location  – the Edit Control Block, a Title, set the RegistrationType to List, and, let’s give it a sequence number of 12345, and set the UrlAction to be

Now, let’s deploy, and see what happens…

Using STSADM, let’s add the solution to our Farm. This will also give us a sanity check, to make sure that we have no errors in our feature. Otherwise, it would kinda yell at us…


Ok, that went well. Now, let’s deploy the solution…


I’ll create a Custom List, Document Library, Announcements List, and a Task List.


And, then activate the feature…


And now, let’s go check the EditControlBlock of our lists…

Checking Tasks… nope.


How about our Custom list…. nope. Not looking good at this point…


And also checking the others…nothing. Well, this didn’t pan out too well. Let’s try something different. Since all content types inherit from the System content type, whose ID is 0x, let’s see if we map to that content type, if we have some success… so, let’s update our ElementManifest to the following…

   1: <?xml version="1.0" encoding="utf-8" ?>
   2: <Elements xmlns="">
   3:   <CustomAction
   4:       Id="MarksCustomAction"
   5:       Location="EditControlBlock"
   6:       Title="Grace-Hunt Website"
   7:       RegistrationType="ContentType"
   8:       RegistrationId="0x"
   9:       Sequence="12345">
  10:     <UrlAction Url="" />
  11:   </CustomAction>
  12: </Elements>

and re-deploy, and see what happens. Let’s check our Custom List…


There it is! Let’s try our Document Library…


There as well! And our Tasks List? Bingo!


And also our Announcements List


So, as you can see, you can get a Custom Action to appear across all list types, by binding your Custom Action to the registration type of List, and  the base content type of 0x, and you can get a Custom Action to work across all list types, as all content types inherit from the System content type, 0x.

For more Custom Action resources, try this search against my blog.


Combining Multiple CustomAction Elements Together

I’ve been slowly, but surely, getting the questions asked during my SharePoint Saturday Boston presentation, so, here goes the next one.

Can you combine multiple custom actions within a feature?

YES! You sure can! In my 4th demonstration (Custom Action Groups), I showed this within my ElementManifest file (manifest.xml), where I defined a CustomActionGroup, as well as 4 additional CustomAction elements within a single manifest file. See code example below:

   1: <?xml version="1.0" encoding="utf-8" ?>
   2: <Elements xmlns="">
   3:   <CustomActionGroup Id="HelpResources"
   4:        Location="Microsoft.SharePoint.SiteSettings"
   5:        Title="CustomAction Resources on MSDN" />
   7:   <CustomAction Id="CustomActionLocsAndIds" 
   8:                 Title="Custom Action Locations and Ids" 
   9:                 GroupId="HelpResources" 
  10:                 Location="Microsoft.SharePoint.SiteSettings" 
  11:                 Sequence="0">
  12:     <UrlAction Url=""/>
  13:   </CustomAction>
  15:   <CustomAction Id="CustomActionElement"
  16:                 Title="CustomAction Element"
  17:                 GroupId="HelpResources"
  18:                 Location="Microsoft.SharePoint.SiteSettings"
  19:                 Sequence="1">
  20:     <UrlAction Url=""/>
  21:   </CustomAction>
  23:   <CustomAction Id="CustomActionGroupElement"
  24:                 Title="CustomActionGroup Element"
  25:                 GroupId="HelpResources"
  26:                 Location="Microsoft.SharePoint.SiteSettings"
  27:                 Sequence="2">
  28:     <UrlAction Url=""/>
  29:   </CustomAction>
  31:   <CustomAction Id="HideCustomAction"
  32:                 Title="HideCustomAction Element"
  33:                 GroupId="HelpResources"
  34:                 Location="Microsoft.SharePoint.SiteSettings"
  35:                 Sequence="3">
  36:     <UrlAction Url=""/>
  37:   </CustomAction>
  38: </Elements>

The person who asked this question had a business need to create a lot of custom actions, however, did not want to have a feature built for each one, even though features are handy ways of deploying functionality to SharePoint, if you have hundreds of features, that can become a management nightmare.

I also mentioned, that what you can do is separate these out into functional ElementManifest files – as you can have any number of them defined in your feature, and they do not all need to be named elements.xml, or manifest.xml. A good example of this can be seen in the 12 Hive FEATURES folder, looking at some of the built in CustomAction elements and CustomActionGroup elements.

For instance, if you wanted to break out your manifest definition files into one for each CustomActionGroup, you can do so easily, by specifying different files – code example below.

   1: <?xml version="1.0" encoding="utf-8" ?>
   2: <Feature xmlns=""
   3:          Id="{FFC864FD-C78D-4fd0-8F18-963D1EA59E0C}"
   4:          Title="SPS.CustomActionGroup"
   5:          Description="Custom Action Grouping example"
   6:          Scope="Site"
   7:          Version=""
   8:          Hidden="false"
   9:          >
  10:   <ElementManifests>
  11:     <ElementManifest Location="MSDNResources.xml"/>
  12:     <ElementManifest Location="BlogResources.xml"/>
  13:     <ElementManifest Location="TwitterResources.xml"/>
  14:   </ElementManifests>
  15: </Feature>


This will make not only the management of features easier within SharePoint as far as managing what gets activated, also the management of the solution as well, so you are not managing 400 CustomAction elements within a single file, you can break them out as needed.

And to answer the question before it gets asked in this entry’s comments – the CustomActionGroup does not need to be defined within the same file as its CustomAction elements. You could break it down into CustomActionGroups.xml and CustomActions.xml if you’d like to separate them out.

Again – the names of the ElementManifest XML definition files do not matter – as long as they are referenced within the feature.xml file (this filename MUST be feature.xml), then you are all set. They really do not even need to have an XML definition, as long as it is declared at the top of the XML file, they will be interpreted as XML files.


RecurrenceId Attribute of the CustomAction Element

During my session at SharePoint Saturday Boston – I mentioned that I would look into just what exactly RecurrenceId does, and make a post about it here. RecurrenceId is a token that is available for the URLAction element within the CustomAction element.

I did some additional research, and was able to find this via MSDN:

“A recurrence identifier that identifies a specific instance of a recurring appointment. It is used with the to uniquely identify the instance.”

The above quote is from an Exchange related article, however, it still fits the bill, and gives a little more useful information than the one found in the RecurrenceId Property link below, which is:

Returns the identifier (ID) of an instance of a recurrent item.

Paul Grenier (AutoSponge) who was attending my session, was spot on with his guess. The RecurrenceId property would be useful in the URLAction element to specifically identify a recurring event list item, and to only act on that specific item, as recurring events within events lists are just one single list item, and not copies of the original with their own specific GUIDs. They have the same GUID as the original event, however, just have an incremented RecurrenceId that can be used to directly identify that specific occurrence of the event.

More information on this SPListItem Property can be found here in the WSS 3.0 SDK: SPListItem.RecurrenceID Property (Microsoft.SharePoint), however, there is not much there.

As of my session on Saturday, I had never needed to use this attribute before in my travels, and virtually the only documentation on it I could find before SharePoint Saturday Boston, was that you cannot use it with the Edit Control Block. This doesn’t make much sense to me however, why it is even available, as I would think the only time this would be useful, is to directly interact with an event list item from the Edit Control Block.


Anyhow – there is now a blog posting out in the wild for others to consume regarding the RecurrenceId attribute. I hope this helps someone else out.


CustomAction Development Resources for SharePoint

A common development task is building out custom actions for SharePoint. What is a custom action you ask? Per Microsoft: “A custom action represents a link, toolbar button, menu item, or any control that can be added to a toolbar or menu that a user sees. Custom actions can be bound to list type, content type, file type, or programmatic identifier (ProgID).” (source)

A good example of a custom action feature in SharePoint is a recently released project to CodePlex – GraceHunt.SharePoint.Features.SiteActionsRecycleBin, which adds a link to the Site Actions menu on any site collection it is activated in, to provide a link to the recycle bin of the current site.

The reasoning behind this post was to list a few great resources which help in building custom actions for SharePoint.

John Holliday has a great (sortable and exportable to excel) list of all of the custom action identifiers, available here:, which lists the Id, GroupId, Location, Sequence, RegistrationType and RegistrationId of all of the Custom Actions built into SharePoint.

You can also build custom action features to hide elements within SharePoint menus, toolbars, and link menus. John Holliday has a great article on locating custom action identifiers to allow you figure out how to find the identifiers for installed custom actions within SharePoint, available here:

This can also be useful to assist in figuring out the sequence number for installing your custom action feature in SharePoint, so you can insert it before or after other items that are currently there.

And last, but certainly not least, MSDN has some excellent resources regarding custom actions

I hope this is useful information, and if you have any resources that should be added here, just leave a comment below, and I will add it to the list.


[Updated 1.28.09]
Over at, there is a growing amount of information regarding custom actions.

Jan Tielens has a good article on Adding Breadcrumb Navigation to Application Pages in SharePoint Central Administration.

André Vala wrote a great post about CustomActions as well, including some great in-depth information on each of the attributes and rights for actions in his post SharePoint 2007 Deployment: Custom Action Features


Speaking at the SharePoint Maine User Group – December 11, 2012


I have the honor of speaking at the SharePoint group with by far the best acronym, SPUGME. Makes me wish I put more effort into the BASPUG acronym! 🙂

I will be up there on December 11, 2012, and presenting The Ribbon UI and Custom Actions in SharePoint 2010.

I am excited to speak at this (fairly new) group, and, to meet some more of the New England SharePoint Community.

For more information on the group, and, for the event itself, please visit:

%d bloggers like this: