Let’s say you have created a declarative custom action for a SharePoint 2013 workflow, like I have illustrated in this post. Now, let’s say you want to update it, changing the .actions4 file or updating its inner workings in the .xaml file.

When you upload the .WSP sandboxed solution, which includes the custom action, and then you activate the feature that deploys the custom action, under the cover SharePoint 2103 creates a folder (with the name of the custom action) under the Workflows folder in your site, as you can see in the following screenshot of Microsoft SharePoint Designer 2013.

Each of the folders, which are inside of the Workflows folder, contains the .actions4 and .xaml files of a declarative custom action, as you can see in the following screenshot.

This behavior happens because the feature element file, which is created by the Visual Studio action template, internally declares exactly to do that. Here you can see a sample Elements.xml file that is related to a sample declarative custom action.

Well now, imagine that you want to update the custom action, as I stated at the very beginning of this post. You can simply update it in Visual Studio, rebuild the .WSP package, release an updated version of the solution and upgrade or deactivate/re-activate the feature. However, it could happen that the action doesn’t upgrade. Do you guess why?

It doesn’t update the action because the Elements.xml file syntax provisions the files just once, and then doesn’t update the .actions4 and .xaml files in case of any future updates. In order to change this behavior, you can simply change the Elements.xml file adding the ReplaceContent attribute with a value of TRUE to each of the File elements. Here you can see the updated Elements.xml file.

That’s all! This way, whenever you will update the feature that provisions the declarative custom action, the files will be overwritten and the action will be updated!