Admins – The Power to Make and the Power to Break

Dear Admins,

You probably have to meet a deadline when your users will get to use the cool new features you provision with the next deployment. But what if the deployment fails? Then you will miss that very deadline.

Did you know you can easily break deployment runs for your org?

Read on to learn why customization changes can break deployments and the recommended preventive measure. This procedure applies to enterprise or unlimited editions.


An Introduction to Breaking a Deployment

As a Admin you get to use all the cool tools to easily customize an org:

  • Data model tools for management of Custom Objects, Custom Fields
  • Workflows for management of Assignment Rules, Field Update rules
  • Record level access rights by managing Sharing Settings and Sharing Rules

An org also contains custom APEX code developed to implement your companies custom business logic. enforces that at least 75% of APEX code must be covered by Unit Tests – best practice obviously is to cover more.

In short: If there is APEX code, there are unit tests.

A best-practice unit test follows this flow of operation:

  1. Create test records (e.g. Accounts, Contacts, Opportunities, Custom Objects etc)
  2. Apply business logic to the test records
  3. Verify results (Test succeeds for correct result / Test fails on error conditions for incorrect results or data)

If you initiate a deployment to your production org the platform will „Run all tests„. By doing that it verifies that every business logic previously deployed to your org will still work as intended (tested by Unit Tests) even after the change, before it potentially breaks functionality for your users. A deployment will be aborted and rolled back if any unit test fails. The paradigm is to „Keep the system running“ because it obviously is impossible to „Never touch the running system“…

The Breaking Changes

How do these worlds connect? How can a Admin, using her tools, break the unit test a developer wrote? Some examples:

Breaking changeImpactPotential solution
Change a field (custom or standard) to be always requiredUnit test code that does not fill this field when creating test records will fail to create the records. Most often seen in the wild with custom fields that were not required to begin with.Change APEX code to populate the required field OR make the field optional again and use the page layout to make the field required. **Check if error message is available to quote**
Change sharing settings for records e.g. to private or change who can read / write which records.This is a subtle one. If the unit test is written according to best practices and running in the context of a non-Sysadmin Profile, access to the record might be denied by to the very unit test that created it.Adapt the APEX code to know about the new business requirements regarding data visibility. By the way, this can be a very subtle on to debug for developers. Potential error message: INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY, insufficient access rights on cross-reference id:[]
Add/modify a Workflow Field Update Rule that interferes with unit test data. Applies to Approval process rejection or approval steps as well.The automated unit test will not see the expected data – and fail. What to do: Adapt the Workflow rule to not interfere with the unit test case or adapt the APEX code to know about the new business requirement the Field Update implementsModify the entry condition of approval processes. Impact: if unit tests need to trigger an approval and the entry condition does not match anymore, the test will fail b/c no or the wrong approval process fires.

What to do about it?

Why is it so easy for a admin to break deployments? It is a great thing to have the admin tools at hand and be able to implement and provision changes for your users quickly. But in more complex Salesforce Orgs the Admins need to be aware of potential conflicts and manually „Keep the system running“:

Any Admin can execute unit tests – any time! Make use of the test execution.

Apex Test Execution Setup MenuFind it in Setup | App Setup | Develop | Apex Test Execution

  1. Run unit tests before change to verify everything is fine
  2. Make your change
  3. Run the unit tests again to verify everything still works.

Once this pattern is used reliably, you might decide to not run tests prior to your changes. In case your change breaks any unit test, developers will love that the single breaking change is known – that eases the process of adapting to that change a lot.

Happy testing & Succesful deploying!


Related resources:

The following two tabs change content below.

Lukas Schroeder

Lukas ist Geschäftsführer und technischer Leiter von APTLY. In dieser Funktion stellt er sicher, dass Anforderungen und Projekte ganz nach den Wünschen und Bedürfnissen der Kunden umgesetzt werden.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.