For working with Call Logs (Task object) to create and for updating I use OpenCTI and hierarchy custom settings as a cache to keep created TaskId.

I have two methods in Apex Controller: when I get the request to insert/update Task I call Apex method to read custom settings and check: has been task created or not. If Task has been created I load TaskId from custom settings and then update exists Task with Open CTI otherwise I create the new Task. Also, I update my custom settings to keep new TaskId if needed.

All worked fine before I ran into a situation when requests began to arrive very often and my code creates two or more Tasks because the check method doesn't find anything in custom settings.

Obviously this is concurrency issue and I need to lock reading/writing operations to custom settings during the first read/update operation isn't completed.

Now methods in Apex Class are static. Perhaps somebody faced with a similar issue and solved it? How I can solve concurrency issues in my scenario? If it is important I need to save all updates from all requests without missing.

  • How do you determine which inbound requests relate to the same Task? – David Reed Nov 11 '19 at 0:52
  • By callId, when I receive the new call I know its callId and I can associate it with taskId which stored in custom settings. – SlavaHq Nov 11 '19 at 6:28

Rather than using a Custom Setting, create a new unique External Id Text field on Activities (which includes Task and Event) to store the Call Id.

Your code cannot reasonably expect to maintain a persistent mapping between Call Ids and Task Ids in Custom Settings.

Instead, store the Call Id on the Task object itself, and handle updates by upserting against this External Id. This should insulate you against some (if not all) species of concurrency problems, but more specificity in solutioning would require a more detailed problem statement and some actual code.

  • can you update the answer to add the point that the "External Id" field should be set as unique - at least, that is the implication of this knowledge article where it says you can have multiple records with the same external ID (even if it isn't recommended). – Phil W Nov 11 '19 at 17:34
  • Good point, @PhilW; updated. – David Reed Nov 11 '19 at 17:46

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.