1

We are running into performance issues/CPU timeouts due to all the Process Builders, Flows, and workflow rules we have on the Case object. In particular these errors occur when we bulk insert Support_Message__c (custom object) records, specifically when the Support Message trigger updates related Cases. See screenshot below:

As you can see in the screenshot, the SupportMessages.updateParentCase method is kicking off Workflow:Case automation that is clearly using the majority of the CPU. My idea is to move that method into queueable apex, as to make the Case update run asynchronously, effectively raising the CPU limit threshold to 60 seconds. I'm guessing the automation contained within Workflow:Case would run asynchronously then. Anyway, that is the approach I'm considering.

Would this approach make the Process Builders/Flows run asynchronously?

6
  • 2
    What is the workflow/Process Builders doing? Are they updating the same case record causing recursion? If so, it'd be beneficial to look at moving that to a before flow or apex instead of staying in WF/PB. Your plan may solve the timeout issue tied to inserting Support_Message__c, but the fact that the PB/WF take so long will still exist. Commented Dec 18, 2020 at 0:32
  • 1
    @KrisGoncalves the flows/process builders are performing record updates to the same case record, causing an ungodly amount of FLOW_START_INTERVIEW polls to be performed in the execution. From a user perspective, since during support message creation we don't need those flows/process builders to run synchronously and provide immediate feedback, I was thinking short term we could move updateParentCase to queueable apex and longer term we could convert some of the flows/process builders to apex
    – ronnie777
    Commented Dec 18, 2020 at 2:11
  • @KrisGoncalves Before (record-triggered) flows supports only updating records that triggered it (as mentioned here). So, I think trying to use that is not feasible at this time, unless Salesforce is releasing updates to it in its next release (that I may not be aware of).
    – arut
    Commented Dec 18, 2020 at 5:18
  • 1
    I probably wasn't clear, but the suggestion for before flow was in tandem with the plan outlined in the question to make the update to the case queueable apex. Which would then trigger the before flow assuming he just needs to update fields values on that same record. Essentially doing what he was planning to do plus take it one step further. Commented Dec 18, 2020 at 13:18
  • @KrisGoncalves That does make sense.
    – arut
    Commented Dec 18, 2020 at 17:42

2 Answers 2

2

arut has already provided the answer to the question (that yes, a queueable apex update would make the Case updates happen in a separate transaction).

I'll take it one step further to suggest not stopping at fixing the problem once you make it a separate transaction as the real issue is slow WF/PB processing on Case. Down the road if it still starts failing as the WF/PB gets slower, you'll have to tackle this anyway and it might be harder/bigger than it is now.

There's this Architect's Guide to Building Record-Triggered Automation on Salesforce Using Clicks and Code that outlines how you can easily improve performance on same record updates by simply moving it to the "before" context (before-save flows for clicks, before update/insert trigger for code). In short, you prevent it from re-evaluating the record again by doing any same-record field updates in the "before" context before it's committed to the database as outlined in Triggers and Order of Execution.

Here are the 3 main takeaways from the guide:

  1. Stop putting same-record field updates into Workflow Rules and Process Builder. Start putting same-record field updates into before-save Flow triggers instead.
  2. Wherever possible, start implementing use cases in after-save Flow triggers rather than in Process Builder and Workflow (except for same-record field updates, in which case see point #1).
  3. If you have high performance batch processing needs or expect highly sophisticated implementation logic, use Apex.

For your situation, takeaway #1 is the immediate win. You will save a significant amount of processing time just moving the Case logic into a before-save flow

enter image description here

enter image description here

1
  • Thank you for your help!
    – ronnie777
    Commented Dec 19, 2020 at 1:05
0

Would this approach make the Process Builders/Flows run asynchronously?

Yes, all asynchronous apex (queueable, schedulable, batch & future) run in a separate transaction. So, wouldn't fall under the transaction processing Support_Message__c object.

Another approach that you can try is to make use of Scheduled Actions in process builder. They are available only for record changes & event processes and they run in a separate transaction. Since, your case is about updating related case records, you should be able to use them. Additionally, you might want to check this out.

1
  • Thank you! :-).
    – ronnie777
    Commented Dec 19, 2020 at 1:06

You must log in to answer this question.

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