We have some custom code from before I joined the company that is showing some unusual behavior.

  1. Code was somehow successfully deployed to production (before my time), and the test code passes within production currently.
  2. Code also passes in all existing unrefreshed sandboxes, but fails on deployment
  3. When I create a new sandbox off of production, the test passes successfully in that new sandbox.
  4. But when I attempt to deploy that same code from the new sandbox to production, the test fails!

I'm aware of 4 possible causes of such mysterious deployment failures:

  • Differences in metadata like validation rules and workflows
  • System.RunAs() statements coupled with differences in profiles/permissions
  • Setting SeeAllData=True and using data that doesn't exist in both orgs
  • Using hardcoded IDs

However, none of those should apply in my situation:

  • No differences in metadata (sandbox was refreshed recently)
  • There is a System.RunAs() statement used, but there wouldn't be any differences in profile perms because, again, the sandbox was refreshed recently.
  • There are no hardcoded IDs nor is seeAllData=True set in this code

Can anyone offer any insight before I enter another epic struggle with SF tech support?

  • (1) Do you have debug logs to look at for the failing test? 2) Can you try deployment via changesets and only run tests on specific classes with debug on; (3) I've had this happen when my runAs() user was not mocked but instead queried from setup data and the user queried, even with same profile, had some subtle variation from the user running in sandbox
    – cropredy
    Commented Feb 4, 2016 at 2:22
  • Let's start with the failed test. What code fails and what is the error message? Commented Mar 7, 2016 at 15:06
  • Thanks for replying. Turns out the issue was actually caused by an approval process, that had been changed from a specified approver to a manually selected approver. The test code in the sandbox (and production) was written under the assumption of a specific approver, and for some reason the test code wasn't failing in production even though it should have been.
    – smohyee
    Commented Mar 7, 2016 at 19:54

1 Answer 1


Turns out the issue was caused by an Approval Process created for the custom object related to the code. When initially deployed, both the sandbox and production's approval process used the user's manager as the approver. After initial deployment, the approval process in only the production was changed, to allow manually selecting an approver.

The test code worked with the assumption of a user's manager being the approver, rather than the approver needing to be specified each time manually. For some reason, this test code passed just fine in production despite this change in production. It also passed just fine in a newly cloned sandbox (which would have copied the new approval process).

The reason it passed is because of poorly written test code on our end. An error was being thrown by the test code, but system asserts weren't properly set up and error catching was put in place, so sufficient code coverage was obtained without throwing any critical errors.

The lesson here: Code failing on deployment despite passing in both sandbox and production? Check for changes to approval process that can be made in between deployments. Also ensure any error handling in your code will still cause test failures where appropriate, instead of hiding problems.

You must log in to answer this question.

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