Form JavaScript returning incorrect saveMode in CRM – Microsoft bug?

I think I may have found a bug in the internal CRM JavaScript, and it is to do with retrieving the saveMode in form script.

As you may be aware, you can determine the save mode by executing executionObject.getEventArgs().getSaveMode() in form script. The return values that you can expect and their meaning can be found here:

This bug can be summarised as the saveMode being incorrectly reported if you save the record to correct a validation error while attempting to deactivate a record.

Sounds confusing? Follow these steps to reproduce this bug:

  1. Attach a script to the OnSave event for a form to report the saveMode
  2. Open an Active record
  3. Clear the value for a mandatory field on the form
  4. Deactivate the record. The form reports a validation error and the record is not deactivated.
  5. Enter some value for the mandatory field in step 3
  6. Click Save or Save & Close
  7. The saveMode is incorrectly reported as 5 (Deactivate). It should be 1 (if you clicked Save) or 2 (if you clicked Save & Close)

This bug can be problematic if you have scripts that checks for the saveMode and performs some logic on record deactivation. I haven’t found a workaround yet. This was tested on 2013 SP1 and 2013 SP1 UR1.


About Bernado

Based in Australia, I am a freelance SharePoint and Dynamics CRM developer. I love developing innovative solutions that address business and everyday problems. Feel free to contact me if you think I can help you with your SharePoint or CRM implementation.
This entry was posted in CRM. Bookmark the permalink.

1 Response to Form JavaScript returning incorrect saveMode in CRM – Microsoft bug?

  1. Joe says:

    It seems like this has to do with a OOTB ribbon button sending or caching a deactivate SOAP request without validating form save compatibility. Depending on the circumstance, it might make sense to replace the Deactivate button with your own javascript button that enforces your form validation rules before sending the SOAP request to the CRM server to deactivate the record. Probably still qualifies as a bug though.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s