Overriding Presaveitem Vs Presaveaction In Sharepoint Forms

The Problem with Default PreSave Logic

The out-of-the-box PreSave logic in SharePoint forms can limit solutions in several ways. By default, SharePoint attempts to save any changes made in a form when the user clicks the Save button. This can cause problems in situations such as:

• Validations – The default save routine does not check for errors, invalid data, or required fields missing values.
• Business logic – More complex logic may be needed before allowing save such as checking permissions, ensuring proper workflows were started, integrating with external systems, etc.
• Conditional saves – In some cases saving should only be allowed under certain conditions based on input values, user permissions, state of other systems, etc.

Without customizing the PreSave behavior these types of requirements can be difficult or impossible to implement robustly. For example developers may resort to client-side script hacks to block the save button under invalid conditions. However this can lead to a poor user experience when saves mysteriously fail for unclear reasons on the server-side.

Customizing PreSaveItem vs PreSaveAction

The PreSaveAction and PreSaveItem events allow customization of save behavior in SharePoint list forms. They are invoked before the standard save logic executes when the user clicks the Save button. This allows PreSave code to:

• Perform validations
• Check business rules
• Conditionally allow / block saves
• Update field values
• Call external services

PreSaveAction is invoked on the parent list object when an item is saved. This allows access to the entire list context along with the item fields. PreSaveItem fires on the specific item object being saved, providing direct access to just that item’s values.

PreSaveItem is most useful when logic only concerns the item itself – e.g. validating fields or updating values for that item. PreSaveAction allows broader context and integration outside the item – e.g. checking permissions, triggering workflows, and integrating with other systems.

A key difference is that PreSaveAction can cancel the entire save operation by setting the Cancel property to true. PreSaveItem can only modify the current item. So blocking saves based on complex conditions is best achieved in PreSaveAction handler code.

Implementing a Custom PreSaveItem

The following example shows custom PreSaveItem code to validate a request status field and block saves if invalid:

“`js
function PreSaveItem(properties) {

// Get current item values
var status = properties.AfterProperties[“RequestStatus”];

// Check if status valid
if (status == “Invalid”) {

// Warn user and cancel save
alert(“Cannot save item with Invalid status”);
return false;

}

// Allow save
return true;

}
“`

The key things to note are:

• Access current and new values through the AfterProperties collection
• Return false from the handler to block the save
• Use alerts or other UI warnings to provide user feedback

This allows SharePoint form saves to be limited based on custom logic while providing a smooth user experience.

Implementing a Custom PreSaveAction

The following PreSaveAction code checks permissions before allowing saves:

“`js
function PreSaveAction() {

// Get current user
var login = new LoginName();
var user = login.GetLoginName();

// Check if user has edit permissions
if(!list.Permissions.AllowEdit(user)) {

// Cancel save operation
Cancel = true;

// Notify user
alert(“You do not have permissions to edit this list”);

}

}
“`

PreSaveAction provides the full list context along with the standard Cancel property to prevent saves. Key aspects in this example include:

• Checking list permissions for the current user
• Setting Cancel = true to block the save
• Alerting the user that permissions are missing

This allows save logic to respect list permissions without confusing users by allowing edits that fail to save.

Additional Tips for Custom PreSave Logic

When working with custom PreSave code, the following best practices help avoid issues:

• Use debug statements and logging – Console.Log or similar logging allows tracking PreSave execution and variables.
• Wrap in try/catch blocks – Catch errors to avoid breaking overall save behavior due to bugs.
• Check list size limits – If allows large lists watch for performance issues.
• Evaluate conditions efficiently – Avoid costly queries; leverage cached lookups where possible.
• Integrate with ItemUpdated event – Use ItemUpdated to catch saves that bypass PreSave by user role exemptions.

Custom PreSave logic takes a bit more analysis than simple column validations. Planning end-to-end save scenarios and testing helps identify any gaps upfront.

Summary

The SharePoint PreSaveItem and PreSaveAction events provide powerful ways to customize form save behavior. PreSaveItem allows validating and modifying per-item field values during save. PreSaveAction enables broader context and canceling saves completely when conditions warrant it.

Overriding default PreSave logic takes more upfront analysis but pays off through robust, consistent save semantics tuned to specific business requirements. Additional configuration and techniques build on these events for even more customization of SharePoint list forms.