I'm starting to explore building a custom save action in WFFM using an implementation of ISaveAction. I know the bulk of my work will be in the Execute() method, but I'd like to know what all of the other properties do. All of the examples that I've found use either a default implementation of the getters and setters (for ActionID and UniqueKey) or else a hard coded response (ActionType.Save for ActionType or ActionState.Enabled for QueryState()). I can't seem to locate any documentation, discussion of what they all do, or any other indication of what the "right" implementation are. Can anyone point me in the right direction?


Sitecore's documentation on the ISaveAction interface is a bit limited, and I can certainly appreciate wanting to know more about it before trying to implement it, yourself. Below, I have provided a detailed breakdown of each of the properties that you mentioned from the ISaveAction interface.

It should be noted that all of the mentioned properties are actually defined on the Sitecore.WFFM.Abstractions.Actions.IAction interface, which is inherited by the Sitecore.WFFM.Abstractions.Actions.ISaveAction interface.

For reference, I primarily used Web Forms for Marketers 8.2 rev. 161129 during my analysis. I looked through a couple of other versions as well, but did not see any significant differences.


The ActionID property is pretty straight-forward: it is the ID of the Save Action item, in Sitecore. It should have a default getter and setter, as Sitecore's internal logic is responsible for setting the property's value. For a Save Action, this happens in the DefaultImplActionExecutor.ExecuteSaving method.


The UniqueKey property of the ISaveAction (inherited from IAction) maps to the Sitecore.WFFM.Abstractions.Actions.IActionDefinition.UniqueKey property, which is a unique string that helps to identify the instance definition of the action on a form. Like the ActionID, the UniqueKey should have a default getter and setter, as Sitecore's internal logic, again in the DefaultImplActionExecutor.ExecuteSaving method, is responsible for setting the property's value.

The purpose of the UniqueKey property is a bit trickier to wrap your mind around, but is a bit easier when thinking about an example. Consider that you have an Email Save Action. There is an item for that Save Action and that item has an ID that maps to ActionID. The default settings for the action are stored on the action item itself, but now assume that you add the action to the form Foo. At this point, you need to update the instance-specific settings for the action (e.g. To, From, Message Body, Subject, etc.) and save the settings such that Sitecore knows that the settings you updated belong only to the instance of the Email Save Action that is on the Foo form. Sitecore doesn't change the template, so instead it saves the data as an ActionDefinition (which I believe is stored as XML). The UniqueKey on the save action then helps to identify the instance of the save action that your class represents.


It makes sense that the ActionType property would be hard-coded for a save action. The ActionType property is typed to the following enum:

namespace Sitecore.WFFM.Abstractions.Actions
  public enum ActionType

Since you are implementing a Save Action, your ActionType is always going to be ActionType.Save. As for the other values, it appears that Sitecore does not currently make use of them. They are likely there for future development purposes that have not yet been made clear.

You can always file a support ticket to inquire about additional information and more clarity regarding the purpose that the other values will serve, but I would expect that Sitecore will give you the same response as I did.


Similar to the ActionType property, the QueryState also makes sense to be hard-coded for a Save Action. The QueryState property is typed to the following enum:

namespace Sitecore.WFFM.Abstractions.Actions
  public enum ActionState

As with the ActionType enum, Sitecore appears to only use the ActionState.Enabled value at present, and the other values are likely included for future feature development. Based on the use of the ActionState.Enabled value and the naming of the other values, I think it is safe to infer that the purpose of these options is to allow the developer to control the frequency in which an action can be called. A Disabled action would never be called, Enabled would always be called, and SingleCall would be called once and would then change to a DisabledSingleCall so that it won't be called again. I'm not sure what Hidden would do, but as with the ActionType enum, we won't know more until Sitecore releases updates that make use of these properties.

Again, you can file a Support ticket with Sitecore to inquire about additional information on this property, but I would expect them to give you the same answer as I did.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.