Hello all -
I've been working on scripts for the last 10 months or so that import data into salesforce using the API (I'm doing my work through python's simple_salesforce module). I've never run into issues with apex timeouts, but suddenly I'm getting inexplicable errors and my scripts are running slowly.
I have reduced my script to just import 1000 accounts and 800 contacts. The accounts import without problem, but the contacts repeatedly fail to import, with the error:
False,False,,"[{'statusCode': 'CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY', 'message': 'npsp.TDTM_Contact: System.LimitException: Apex CPU time limit exceeded', 'fields': []}]"
Approximately 600 of the 800 contacts fail to import with this error. The insert is also very slow, although I suspect the slowness is related to the error: I have found that inserts with errors run far more slowly than inserts that run smoothly.
I don't believe that anything has changed in either my instance or in my script. In fact, I successfully ran a 30,000 contact import just 2 weeks ago.
The errors I am seeing are in my developer pro sandbox; it also occurs in a normal developer sandbox.
In order to trouble shoot the problem, I have reduced my batch size for contacts to just 200 contacts at a time and my inserts are happening serially in case row locking is the cause of the problem. I have also turned off a few of my process builder triggers that would run against contacts. THey shouldn't be the cause of the problem because they haven't changed in 2 years.
Does anyone have a clue as to either what may be going on or better ways to troubleshoot?
Thanks,
Mike
Great you are getting around the performance issue. The NPSP Managed Package has no major updates for a while now and not sure why a default setting will impact your specific Org. It won't hurt to open a Support Case with Salesforce to inquiry if they have any insights.
If you don't want to dig through the actual processing Automation causing Apex CPU Timeout following the provided link, you should consider change the way you load data.
Try this:
First import accounts to create the Household account; then import Contact and map the newly created Account ids to the Contact records. You will need to disable the NPSP Household Auto Creation first through NPSP Settings.
Sushil Kumar (UKG) 
Forum Ambassador
download Salesforce setup audit trail. You will find all org changes over there.
Hi,
Salesforce CPU time limits usage to 10 seconds for synchronous transactions and 60 seconds for asynchronous processing. The “Apex CPU time limit exceeded” error means your transaction is taking too long and can’t be completed. In your case, your CPU Time out is error out at the NPSP TDTM Contact Trigger Handler: npsp.TDTM_Contact.
To get details what's causing the exact time out, reference to this Blog for detail steps: https://www.apexhours.com/apex-cpu-time-limit-exceeded/
Did you review your Python script calling what kind of Salesforce API? Is it Synchronous or Asynchronous? If you are using Synchronous you should review option to call the Asynchronous API?
Sushil Kumar (UKG)
Forum Ambassador
Seems like npsp package has some code which is running on insert. I am assuming there is no way to turn off these triggers using some custom setting or your requirement is to keep them on them during load. In that case, only alternative is to reduce batch size. 200 is standard batch size for every transaction, so I would go even lower like 100. And turn off whatever you can to keep transaction time lower. Thank you for reminding me to update this question. I've had a hell of a run trying to figure this out and fix this.
Long story short, the problem more or less went away on its own. There is no good explanation for what happened and why it was suddenly fixed, although I know the direct cause of the slowness on my server. This comes through working with SFDC support for several weeks.
The basic issue is that there were 550 npsp triggers on my server. You can find out the number on your server by running "select count(Id) from npsp__Trigger_Handler__c " on the dev console. NPSP normally has just 55 triggers (if you have a new sandbox, you may have 0 until you go to NPSP settings). I don't know how all of these triggers were created but having them all clearly caused a problem with my imports. When I refreshed my sandbox a few weeks after the problem first came up, the triggers were normal again and I never had the same level of issue in the past.
Two other things that I did early in this process that were helpful before I figured out the bigger issue:
1. I had DLRS turned on with some scheduled rollups that were being triggered by my imports. After running my script a few times, there were ~100k DLRS rollups scheduled that hadn't run. That was slowing things down a lot.
2. I turned off the few DLRS rollups that were directly implicated by my script and will reactivate them with a full recalculate when I am done importing.
I can't say that the issue disappeared fully - I just did an import this morning and got quite a few errors, but many fewer than before:
"'CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY', 'message': 'Too many retries of batch save in the presence of Apex triggers with failures: when triggers are present partial save requires that some subset of rows save without any errors in order to avoid inconsistent side effects from those triggers. Number of retries: 2', 'fields': []}]""
I am having this problem too, with simple updates to the HomePhone field. It just started a week or so ago.
As an update, I recently created a ticket with Salesforce and have been methodically trying to work through solutions with them. I have sent them debug logs, which hopefully will shed some insight.
One thing that I was able to do that did improve but not fix my outcomes: I removed all DLRS lookups and disabled all DLRS triggers. When inserting 20000 contacts, only 1500 of them failed in the manner described above. That still is problematic and far worse than what I had previously achieved (no APEX errors) prior to my recent refresh. But it points at least partly in the right direction.
To continue my diagnosis of this issue:
I am able to import contacts as I previously was able to as long as I change one setting in NPSP: I turn on "Simple Address Change Treated as Update". See below:
My assumption is that something has changed within Salesforce or NPSP, although I don't know what, that has made address updates a more 'costly' apex operation. I haven't changed any of my data or code, but SF has stopped working the same way when I don't have "simple address change" checked in NPSP.
For now this is a satisfying answer b/c I can fix my problem, but it isn't satisfying to not know where the problem lies.
Thanks for the thought, Robin. I am actually already doing that - I import accounts, keep track of the account Ids, and then insert contacts using the account ID that I already inserted.
I've continued to work through this problem. There were only a few changes on our system that we made that could have impacted this, namely we created some new DLRS rollups on contacts. I disabled all realtime DLRS rollups, but no luck - I still get problems.
In further working through this, I updated my script to import a SINGLE contact and I can recreate the error. Sometimes the error comes up with the APEX exception from before, but frequently, now, I get a different error: "npsp.TDTM_Contact: System.LimitException: npsp:Too many SOQL queries: 201'"
As with other insert errors that I've had in the past with the API, I've found that systematically working down to the field that may be causing the error can be helpful. What I have found is that I can successfully import contacts as long as I remove the 5 mailing address fields: mailingstreet, mailingcity, mailingstate, and mailingpostalcode. Including any of them (I've tried different combinations) seems to cause the error.
Why could that be? What in NPSP or anything else in SF would cause insertion of a contact with an address to fail, but without an address to be fine? Is there some sort of lookup happening on the backend to see if the contact's address is the same as the household and creation of a new address object if they are different?
