Hi there!

If you are working with Salesforce, at some point you will somehow get in touch with Salesforce deployments which are not so easy to master as they are having multiple caveats.

So I created this list of some common Salesforce deployment errors I dealt with, with a possible solution on how to fix it.

1. Missing/ Wrong references or dependencies

ERROR:

• Method does not exist or incorrect signature
• Variable does not exist
• System.NullPointerException: Attempt to de-reference a null object. Deployment Failed due to Missing Dependencies

SOLUTION:

• This error occurs when a deployment is missing a dependency, such as a custom field or object. To fix this, you need to review the deployment package and make sure all the necessary dependencies are included.

2. Missing characters in code

ERROR:

• Expecting 'x' but was: 'y'
• Missing ';' at 'y'
• Unexpected token 'x'

SOLUTION:

• If you have trouble with that, make sure you have installed officialy recommended plugins by Salesforce.
• There are also some other plugins in the marketplace like SonarLint that will analyze your code in terms of Bugs, Vulnerabilities and CodeSmells
  (lightweight scanning; heavyweight scans can be run on a dedicated server like SonarQube/SonarCloud)
• Also make sure you have checked our plugins for Salesforce

3. Code Coverage failure

ERROR:

• Your code coverage is 0%. You need at least 75% coverage to complete this deployment

SOLUTION:
Include running unit tests during your deployment that will cover apex classes/triggers which you are deploying. While you can deploy these components without unit tests to sandboxes, for a Production deployment you have to include them. You can have different levels of Unit Tests while deploying:

• NoTestRun (not applicable for Production)
• RunSpecifiedTests (specify only selected unit tests by name)
• RunLocalTests (runs all unit tests apart from these in managed and unlocked packages – default level for Production Deployments)
• RunAllTestsInOrg (runs all unit tests in org, even these in packages)

When you use RunSpecifiedTests also check for any references of your class in other Unit Tests (Ctrl + Shift + F in Visual Studio Code). Sometimes you will only get 75% coverage with multiple unit tests that are named differently from your target apex class.

4. Other operation already in progress

ERROR:

• UNKNOWN_EXCEPTION: admin operation already in progress

SOLUTION:
There can be multiple reasons why above error occurrs:

• Deployments are scheduled one after another, wait some time after scheduling the next one
• Some background job is performing access lock. You may check the Apex Jobs, Apex Flex Queue or Background Jobs tabs in Setup to find potential causes
• Multiple apex tests are running in parallel.
  You can disable parallel apex test by going to Salesforce Setup > Apex Test Execution > Options (button) > Disable Parallel Apex Testing = checked
  Just wait some time and retry again

5. UNABLE_TO_LOCK_ROW unable to obtain exclusive access to this record

SOLUTION:

• Try solutions described under 4. Other operation already in progress
• Ask developers to perform an investigation as most probably this will be re-occurring pain
• Check this official Salesforce support page – Error ‘Unable to lock row – Record currently unavailable’

6. Missing Permission issues

SOLUTION:

• This error occurs when the user deploying the package does not have the necessary permissions to deploy the package.
  To fix this, you need to review the user’s permissions and make sure they have enough to deploy the package.
  The easiest is to just assign a system administrator profile.
  Also, look for assigned permission set licences and checkboxes on the user detail page (i.e. Knowledge User, Service Cloud User)
  I would say best practice is to have a separate user for deployments like a CICD service integration user.
  This user can have API only access, but also full access to all fields, objects, etc.

7. The client has timed out

SOLUTION:

• Sometimes is the version of your CLI, so update/downgrade SFDX CLI and SF CLI (these two are now different things where Salesforce enforce switching to SF)
• You can also try to check deploying without VPN or with a different network
• Try setting new environment variables:
  • SFDX_DNS_TIMEOUT = 120
  • SFDX_DOMAIN_RETRY = 320
  • SFDX_REST_DEPLOY = false

8. The dependent class is invalid and needs recompilation

SOLUTION:

1. See the stack trace of the message and examine carefully
2. If all seems fine just go to Setup > Apex Classes/Triggers (depending on which one of these 2 is failing)
   i. Click on "Compile all classes/triggers hyperlink" and wait for results in a yellow box.
   It can take some time so be patient.
   Best to copy paste the output and place as a note or a task in backlog
   ii. Fix the issues, then compile again and try to deploy afterwards

9. SQLException while executing plsql statement

ERROR:

• 
  PLS-00306: wrong number or types of arguments in call to 'MARK_USED_AUTO'
  ORA-06550: line 1, column 7:
  PL/SQL: Statement ignored
  This almost certainly means your PL/SQL is out of sync with your Java. Rebuild and then run ./ant plsql.
  SQLException while executing plsql statement: {?=call cApiCursor.mark_used_auto(?)}(01g5400000qodhQ)```

SOLUTION:

• That’s a bonus one explained under Stack Exchange
• Replay deployment, and if that continues to occur just contact Salesforce Support Team using help.salesforce.com and log them a case.

10. Duplicate Username

ERROR:

• System.DmlException: Insert failed. First exception on row 0; first error: DUPLICATE_USERNAME, Duplicate Username.
  The username already exists in this or another Salesforce organization

SOLUTION:

• Most probably, within Unit Test you are creating a user. Make sure the username is unique across all Salesforce Organisations. I mean ALL environments, including all Salesforce Clients, not only the company you are working for.

11. Assertion Failed

ERROR:

• System.AssertException: Assertion Failed: Expected: 1, Actual: 2

SOLUTION:
Isolation of Test Data from Organization Data in Unit Tests

It’s important to remember that objects like:

• User
• Profile
• Organization
• CronTrigger
• RecordType
• ApexClass
• ApexTrigger
• ApexComponent
• ApexPage

are accessible in Unit Tests even if the test is not marked as IsTest(SeeAllData=true).

This can cause Assertion failures.

Let’s take a look at the example below:

insert new User(
   Alias = 'standt', 
   Email='standarduser@companyname.com', 
   EmailEncodingKey='UTF-8', 
   LastName='Testing', 
   LanguageLocaleKey='en_US', 
   LocaleSidKey='en_US', 
   ProfileId = [SELECT Id FROM Profile WHERE Name='Standard User'].Id, 
   TimeZoneSidKey='America/Los_Angeles', 
    UserName='standarduser@testorg.com'
);

List<User> testUsers = [SELECT Id FROM User WHERE Email = 'standarduser@companyname.com'];

Assert.areEqual(1, testUsers.size());  // Fail

If you have a user in the environment with Email = "standarduser@companyname.com", you will get that record in the query results as well.

And that’s all for today. I may update this post in future so if you know any better solutions to mentioned above issues or want to add something to the list feel free to use a comment section.

You can still post as anonymously without registering – Just click on the "Name" text area and then select the checkbox "I’d rather post as a guest"