Mitch Milam's Dynamics CRM and xRM Discussions

While working on a customer project recently, we added logic to prevent the user from saving should certain form conditions exist.  During testing, we found that Save events were coming from a variety of unexpected places.

Take for instance the Opportunity Entity.  There are several related entities connected to Opportunity:

Clicking on the Orders link on the Opportunity allows you to  review or created new associated Orders.

When you click the New Order button on the Orders pane, one of the first actions it will perform is to save the parent Opportunity with an internal call that looks something like this:

crmForm.SubmitCrmForm(21, true, true, false);

How This Causes Problems

This system-originated save caused a problem in our solution because we had actually removed the Save and Save and Close buttons until our approval processes had been completed.  This “save from nowhereâ€? broke our validation processes.

Making Your Save Process Solid

If you review the OnSave event documentation on MSDN ( or or the SDK help file ), you’ll see that you can actually determine from where the save originated.

The property event.Mode will contain the origination point for the save activity.  In our case, we only wanted the OnSave event to fire if the event.Mode was 1 ( Save ), or 2 ( Save and Close ).  The code looks like this:

if (event.Mode == 1 || event.Mode == 2)

{

}

Finally, if it turns out that you need to watch for a specific save event, the first parameter of the crmForm.SubmitCrmForm will contain value that will be used to set the event.Mode.

Stopping the Save

As you will see in the SDK documentation, you can actually stop the save from occurring, using the following code:

event.returnValue = false;

This is useful should you need to inspect the form state and only allow the process to complete if all checks pass.