What is hiding behind CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY?
CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY is a wrapper. A trigger, or code a trigger calls, hit an exception it did not catch, and Salesforce reports the DML as failed with this status code. The name tells you nothing useful on its own.
Read the words after caused by:. That is the real error. In the example below it is a NullPointerException, but it can be a SOQL limit, a different DmlException, a QueryException or anything else Apex can throw.
Why does a trigger error show up as a deploy failure?
- The trigger assumes a value that the test record does not have. A lookup is empty, a related record was never created, or a map lookup returns null.
- The trigger is not written for bulk. One record works, and a loop with SOQL inside hits a limit.
- A new trigger now runs during tests that insert the object, so tests that used to pass break. This is the usual reason a deploy fails on a test you did not touch.
- The trigger depends on a custom setting, a custom metadata record or a user setting that exists in the sandbox only.
What does the failure look like in Deployment Status?
A before-insert trigger on Account that dereferences a null variable, plus a test that inserts an Account. Check-only deploy with RunSpecifiedTests:
AccountSeedTest.insertsAccount
System.DmlException: Insert failed. First exception on row 0; first error: CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY, AcctDefaults: execution of BeforeInsert
caused by: System.NullPointerException: Attempt to de-reference a null object
Trigger.AcctDefaults: line 4, column 1: []
Class.AccountSeedTest.insertsAccount: line 4, column 1
The first stack line is the trigger and the line that threw. The second is the test line that caused the insert. In an org with a namespace, the trigger name carries the prefix.
How do I fix it in Setup?
- Find the failing test in Setup > Deployment Status > View Details. Copy the text after
caused by. - Open the trigger at the line in the stack. Look for anything that can be null: a lookup,
Map.get, a list index, a parent field. - Guard it. Check for null before you use the value, and build maps from the data you actually have.
- If the trigger is fine and the test data is thin, give the test what the trigger expects. Add the related record or the custom setting row.
- Run the test in a sandbox: Setup > Apex Test Execution > Select Tests > Run. Then validate again.
How do I fix it with the CLI?
sf apex run test --class-names AccountSeedTest --result-format human --wait 10 -o <sandbox-alias>
sf project deploy start --dry-run --source-dir force-app --test-level RunSpecifiedTests --tests AccountSeedTest -o <target-alias>
To see the trigger run in detail, open Setup > Debug Logs, add a trace flag for your user, run the test again, and read the log for EXCEPTION_THROWN. Keep the log level low outside this step, since debug logs fill up fast.
How do I stop a new trigger from breaking other tests?
Write triggers in bulk, as the Apex guide describes: collect Ids in a set, query once, keep results in a map and read from the map (Apex Developer Guide). Keep triggers thin and put logic in a handler class that has its own tests.
When you add a trigger, run every test class that inserts or updates that object, not only the one for the trigger. A new trigger changes what every one of those tests does.
Clientell AI runs the covering Apex tests before you approve a deploy, so the trigger line that threw shows up first. See AI Salesforce deployments. Background: trigger and Apex in the glossary.
Other test-time failures: coverage below 75%, assertion failed, validation rule in a test, callout in a test.
Questions about CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY
Is CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY a Salesforce bug?
No. It is how Salesforce reports that code attached to the save threw an exception. The cause is in your code or your data.
Why do I see it on a test that I did not change?
Someone added or changed a trigger, flow or validation on the same object. Each test that saves that object now runs the new logic.
Does the same code pass in the UI?
It can. In the UI, the record often has fields the test left empty. The test is a stricter, emptier case, which is why it finds the null.
How do I know which part of the stack is mine?
Lines starting Trigger. or Class. are your code. The top one is where the exception was thrown. The ones below show how execution got there.