FCI Trigger(s) Flagged During Salesforce Org Assessment

The Issue

When the Salesforce Governance Team performs an Org Assessment, they will sometimes flag certain triggers that take longer to run. They will typically suggest that the customer reach out to the vendor to optimize these triggers.

Here’s the challenge: Many different elements contribute to a trigger’s runtime, and some of those elements are outside the scope of Full Circle’s — or any other vendor’s — control. This article will address some key points regarding trigger performance and lay out some of the ways Full Circle can help reduce Elapsed Time for triggers in your org.

What Does "Elapsed Time" Mean?

Elapsed Time refers to the total time from when a trigger fired until it exits. There are two scenarios to consider here:

1. When the trigger does not update the database
2. When the trigger does update the database

If the trigger does not update the database, it’s fairly simple to see where Elapsed Time goes: Time is consumed by Apex, and by any database queries performed by the code. Full Circle is able to optimize our own Apex Code, and our platform already does so by default. All of our code is designed to be bulk-safe and highly scalable.

When the trigger does update the database — with SOQL, or queries — it can be harder to see where the time goes. While Full Circle has no control over the underlying database, there are ways to design queries to perform well, and we adhere to these best practices. However, query performance can also depend on the data in your specific org. As a result, it’s possible that a query designed according to best practices won’t perform as expected in the unique context of your org. This situation is an outlier, and it’s not typically what’s happening when Salesforce Governance flags a trigger. The good news is that Salesforce can identify these outlier situations and provide detailed technical information that enables us to optimize them.

More on Triggers and Elapsed Time

Most triggers, including those used by Full Circle, also update the database. When this occurs, a variety of different elements come into play during the trigger execution.

When Full Circle’s trigger performs a database update, other triggers and automations fire. In turn, these triggers and automations may perform database updates, which fire additional triggers, and so on. They may even fire the same triggers. This cascading effect is the primary cause for longer trigger runtime and CPU limit errors. Many elements in this cascade are out of Full Circle's control, but because they occur during the Full Circle trigger invocation, they all count toward that trigger's elapsed time.

Fortunately, the Full Circle application does provide a way for your code and automation to know when we are doing the update so you can bypass unneeded functionality. You can find more information on how to do this in the following section.

Trigger-Specific Guidelines

Our developers put a great deal of effort into optimizing our Apex code and queries. That said, the amount of time the triggers use will also depend on how your application is configured. Here is more detailed information on those triggers:

FCR_CampaignMemberTrigger

Funnel metrics are tracked on CampaignMember object, so Full Circle has a lot to do during this trigger. Naturally, we’ve worked particularly hard to optimize it.

During the before trigger, we may insert a new Campaign if repeat responses are configured. This rarely takes much time, nor does it typically cause problems.

During the after trigger, we may update leads and contacts. This is where problems are most likely to occur, as many orgs have lead and contact triggers and automation. If these then try to update the CampaignMembers again, you have reentrancy, which inevitably leads to long elapsed times and greater CPU time usage when operating on multiple records.

To optimize these triggers:

• Use our Admin Update Counter to disable your triggers and automations when Full Circle is updating leads or contacts.
• Set the scoring batch size to a smaller number. This moves larger batches to execute scoring asynchronously – which removes the lead or contact update from the trigger and moves it to an asynchronous context.

FCR_LeadTrigger and FCR_ContactTrigger

Our lead and contact trigger generally do not consume much time on their own unless you have an abundance of sync fields configured and are updating a large number of active leads or contacts. Our software tries to identify these scenarios and move those sync operations into an asynchronous context, but it sometimes guesses wrong.

These triggers may also update CampaignMember objects. This also leads to invocation of any triggers and automation on the CampaignMembers. If they, in turn, try to update lead or contacts, you once again have reentrancy issues that can consume large amounts of CPU time and lead to excessive elapsed time.

To optimize these triggers:

• Use our Admin Update Counter to disable your triggers and automations when Full Circle is updating leads or contacts.
• Reduce the number of configured sync fields.

FCR_AccountTrigger and FCR_TaskTrigger

If you have person accounts enabled, the FCR_AccountTrigger trigger behaves exactly the same way as the FCR_ContactTrigger trigger with regards to person accounts. Please refer to the relevant section above for more details.

Otherwise, any reports that suggest problems with these triggers are simply incorrect. It can be difficult to interpret debug logs, and it’s possible to attribute time to the wrong triggers. This is especially true because our trigger calls a system function to determine how much CPU time has been used, and sometimes CPU time is incorrectly attributed to the trigger that called that function.

Other than person accounts, our FCR_AccountTrigger exits quickly therefore should not cause any issues.

The FCR_TaskTrigger always exits quickly. It was created for functionality that has not as yet been released, and is disabled on all customer orgs, so it should not cause any issues.

If you receive a report identifying these triggers as problem areas, please ask the reporter to reach out to Full Circle Support so we can help them understand that their analysis is incorrect.

Additional Steps

Along with the above methods for optimizing triggers, we recommend that you take two additional steps if Salesforce Governance flags a Full Circle trigger in your org assessment.

Capture a Debug Log

For those of us outside of Salesforce, a debug log is the only tool available to identify where time is being consumed in a trigger (whether it is Full Circle Code, queries, other code, or automation). Your Salesforce Admin can analyze debug logs using the Apex Log Analyzer, which can be downloaded here. You will want to capture both Apex and Automation at the debug log level or higher in order to get an accurate reading. For more information, please refer to the relevant section of our support documentation.

Request Additional Technical Information

During org assessments, the Salesforce Governance Team often flags triggers or other operations that take a long time. But often they do not, by default, provide sufficient technical information to identify where the time is being used. This results in an overly simplistic message to “work with the ISV to optimize the trigger.” In and of itself, this is not helpful information. Salesforce has the ability to provide more detailed insights.

You can reach out to the person(s) that performed your Org Assessment and/or provided the report for more in-depth technical information as to which callout is taking a long time. You can also log a case with Salesforce Support to request this information. If you are unable to gather the requested information from Salesforce, we will be happy to work with you to try to get them to provide it. This information is needed to accurately assess where time is being used. In the event that they, or we, identify an area where our code is not optimal, we will address those as quickly as possible and release the necessary patch.