I have a custom object that creates a calendar event via a trigger and it works fine. However, if the user attempts to change calendar event fields from the calendar edit feature, I want the fields to revert back to the last value thus essentially denying the change (i.e., only allowing the fields to be changed in the custom object). I used a before update and removed the update DML expecting the fields to revert back to the old values. Using developer console I can see that ALL of the fields revert to their old values including the Start and End datetime fields. However, the Start and End datetime fields are somehow being overwritten again with the new values.

trigger prohibitUpdate on Event (before update) {

for (Event newEve : Trigger.new) { Schedule_Onsite_Technician__c e; Event oldEve = Trigger.oldMap.get(newEve.id);

if (stopRecurssion.runOnce()) {
    e = [SELECT Id FROM Schedule_Onsite_Technician__c WHERE Id=:newEve.WhatId LIMIT 1]; //determine if this event was originally created by the customer object

    if (e != null) { //if there is a custom object record then keep old values
      newEve.StartDateTime = oldEve.StartDateTime; 
      newEve.EndDateTime = oldEve.EndDateTime;
      newEve.Onsite_Arrival_DateTime__c = oldEve.Onsite_Arrival_DateTime__c;
      newEve.Onsite_Completion_DateTime__c =  oldEve.Onsite_Completion_DateTime__c;
      newEve.Location = oldEve.Location; 
      newEve.Description = oldEve.Description; 
      newEve.OwnerId = oldEve.OwnerId;
      newEve.ShowAs = 'OutofOffice';
      newEve.Subject = oldEve.Subject;
      newEve.WhoId = oldEve.WhoId;

  catch(exception ex){

} }

  • What is the issue? are you saying that its updating the event or not updating event? May 16 '14 at 5:02
  • while using the developer console I can see that the variables are being updated as desired, i.e., the old values are overwriting the new values. When subsequently viewing/editing from the calendar all of the values are the sames as the old values except for the start and end datetimes which reverted 'forward' to the new datetimes even though the developer console indicated they had been changed to the old values.
    – Steven J
    May 16 '14 at 22:40
  • Did you check to see you don't have other triggers/workflow field updates on Event?
    – cropredy
    May 17 '14 at 0:42
  • This is the only trigger on the event.
    – Steven J
    May 17 '14 at 14:06
  • if i understand it now, is a better title for this post: "Changes to trigger.new upon Sobject Event within before update are not sticky" ?
    – cropredy
    May 17 '14 at 16:23

used a before update and removed the update DML expecting the fields to be updated but they were not.

This is working as intended. In a before update trigger you do not need to use an update call to set the values, because you're essentially setting them to new values before they hit the database. Therefore, in the trigger posted, the code that's intended to keep the old values is working as it should and preventing those fields from being changed.

You'll need to use some other kind of flag to determine when this logic should be run and when it shouldn't, for example you could use a boolean field on the record, or if this is going to be triggered by some other code (a trigger on a custom object for example) you could use a static boolean and test the value of that.

  • Thanks! The problem is that the new value remain not the old values. Practically speaking, I create the calendar event from the custom object, everything is fine. Then I go to the calendar and edit the event changing the startdatetime and enddatetime. On the calendar the event is shown with the new datetimes, while the custom object has the old datetimes.
    – Steven J
    May 16 '14 at 13:06
  • I'm confused as to what you're actually after. If you want the times to be the same as those in the custom object you'll need to copy them from there by querying that object in the trigger.
    – Matt Lacey
    May 17 '14 at 2:08
  • Sorry for the confusion. The use case is a manager uses a customer object (SOT) to schedule technicians for onsite visits. Upon creation of the SOT record a calendar event is also created. Only the manager is allowed to change any of the fields. The SOT trigger works fine ... can create and edit/update as wanted with the desired results.
    – Steven J
    May 17 '14 at 13:53
  • premature CR and time out problem while editing. rest of comment is: Want to prohibit other users, including assigned tech, from making changes to the calendar event and thought the code would be simpler by just rejecting any changes and reverting back to the old entries. Your suggestion clearly will work, but now it's principle to fix.
    – Steven J
    May 17 '14 at 14:05

Two additional Event fields had to be overwritten:

newEve.ActivityDateTime = oldEve.ActivityDateTime ;

newEve.DurationInMinutes= oldEve.DurationInMinutes;

Apparently there is logic associating these fields with the new StartDateTime and EndDateTime fields. If there is an inconsistency, then the "old" values are rejected and the "new" values are used.


Salesforce has made it mandatory to include the two required fields ActivityDateTime and DurationInMinutes in parallel to the startdatetime and enddatetime field. In this case we are trying to update the values from new version of the record from older version of the record. So we need to include activitydatetime and durationinminutes also. I guess salesforce didn't document this behavior in their help articles.

Nirmal Christopher
SFDC Technical Consultant Global tech & Resources,Illinoi, USA

  • Nirmal, maybe it's a good idea to update your username (user8677) to your real name, and mention anything about you on your profile. That's the recommended method on any stackexchange site. Jun 3 '14 at 12:40

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.