Skip to main content

This is astounding to me that this is the first time I noticed this.

Try this.

  1. Edit an Event StartDateTime value in Skuid.

  2. Notice how the EndDateTime value hasn’t changed?

  3. Now save the event and notice how it changed?

  4. It’s staying exactly X minutes into the future based on DurationInMinutes.

So, editing the StartDateTime value of an event should always update the EndDateTime according to the DurationInMinutes. This is how Salesforce LEX and I think Classic does it.

Ah, the bliss of “standard” objects :) 


This has come up a number of times over the years, here’s another post about the same issue and how to address it:


https://community.skuid.com/t/calendar-bug-startdatetime-enddatetime


Short story — you have to force an update to both StartDateTime and EndDateTime as part of the same save transaction in order for Salesforce not to mess with one or the other behind the scenes to preserve a constant DurationInMinutes. If the save request explicitly includes values for StartDateTime and EndDateTime, then the DurationInMinutes will be reevaluated server-side to reflect the new difference between end and start, whereas if only start/end are sent up in the save request, Salesforce will adjust the one that was not modified to maintain a consistent duration.


Salesforce does this in other situations as well with standard objects, e.g. OpportunityLineItem, where if you modify the Quantity but not UnitPrice, then the UnitPrice will be adjusted to maintain a consistent TotalPrice, whereas if you explicitly modify both Quantity AND UnitPrice in the same save transaction, then TotalPrice will be adjusted server-side to reflect the new Quantity*UnitPrice. 


So the “standard” SF UI (in Lex/Classic) is being “non-standard” in these situations in that it is listening for changes to one field and auto-populating a change in the other to ensure that Duration/TotalPrice gets modified behind the scenes.


As described in that other community post — best way to “force” a change to both fields is to do some Model Action / Formula logic in response to changes to either of those fields and ensure that a change is made to the other field as well. What I’ve done in the past (not the only solution) is to create a “Temp” field and then do this:


  1. On Change to Start/End — dump current value of the other field (End/Start) into Temp. 

  2. Update End/Start to a dummy value guaranteed to be different from the current value for End/Start — effectively forcing Skuid to consider a change to have been made.

  3. Update End/Start to be Temp (which contains the original value). At this point Skuid thinks End/Start got changed, even though it didn’t really, and the save request will contain values for both Start and End.


I actually would prefer that Skuid auto updates the end date by the same amount of time that the start date changed. This is what I like about how LEX handles this. The user experience is otherwise horrible when dealing with Event times out of the box.


Reply