1

I make a callout by clicking a button on the page layout of a record(object-ABC). The record details are sent to external systems(another salesforce) system that creates a Case record in the external system. It sends a response with the record Id of the Case and the status of the case back. I update the case Id and status on the record(object-ABC) where the integration was initiated using the response I receive from the external system.

The Challenge : I have a unique scenario here , I have validation rule on object-ABC which does not allow a future date(>today()) for a field named=> Enter_a_date__C. The user who creates record of ABC object is in New Zealand time zone and is able to enter 9th Aug in the Enter_a_date__C field. All fine until now. The problem occurs when another user with an US Pacific time zone PST tries to click the button to make a callout to external system to create a CASE. The case gets created however while updating the case ID and Status back in record(object-ABC), the validation rule fails and throws an error saying Enter_a_date__C cannot be a future date. This is because the user is in pacific time zone and when the Case id and status are updated on the record the validation rule kicks in and fails the record.

What are possible options to overcome this? Is there a way to roll back the CASE that was created in external system if there is a scenario like this? Any suggestions.

Improve this question

1 Answer 1

Reset to default
1

One option is to change the Enter_a_date__c field to be a DateTime. Since it will now be storing the value in UTC it won't matter what timezone the user creating the value is in.

Another option is to detect users in a negative timezone and bump the date forward as required. This would probably open you up to a number of challenges, so I'd definitely go with the full DateTime option if you can.

Improve this answer
2
  • Thanks!! Changing to date time might work for me but I have to check the impact of that on the business(I am guessing there wont be any). I am assuming there is no other way to handle this situation , is that correct?
    – SfdcBat
    Commented Aug 9, 2017 at 1:04
  • 2
    There would be other ways, but they would have much greater elements of "hackiness". By switching to a field type that understands timezones all of those problems should go away. (Assuming you don't lose the timezone details as some point. If in doubt - keep every value at UTC)
    – Daniel Ballinger
    Commented Aug 9, 2017 at 1:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .