Skip to main content
Solved

Test Site vs Production Site Customizations Unexpectedly Affecting Prod & Frequent CPE Unpublishing Issues

  • December 12, 2025
  • 1 reply
  • 14 views

Hi everyone,

We’re running into a strange issue and I’m hoping someone here has faced something similar.

In our environment, we have a Test site and a Production site. The expectation, of course, is that publishing a customization package (CPE) to Test should not impact anything in Production. However, we are noticing situations where:

  • A field added and published only in Test suddenly appears in Prod

  • Customization packages in Prod seem to get unpublished and republished automatically

  • With 3–4 developers working simultaneously on different customization projects, it’s becoming difficult to trace the root cause

We are trying to understand:

  1. Is there any scenario where publishing to Test can affect Production indirectly?

  2. Has anyone experienced customizations appearing in Prod even when the package was never published there?

  3. What best practices do teams follow when multiple programmers are working on the same instance?

  4. Any suggestions for preventing CPEs from being overwritten or unpublished unexpectedly?

Any insights, lessons learned, or troubleshooting tips would be really appreciated. We're trying to put better processes in place, but we want to understand whether others have seen similar behavior and how they resolved it.

Thanks in advance!

Best answer by Django

Alas, publishing does impact all tenants to certain degrees. They aren’t as segregated as we’d like. 

What I do when I need to introduce a new feature that we need available in one tenant, but not another, is to create a switch to toggle the new behaviour on and off. I’ll usually append a boolean field to one of the Setup tables but you can make your own for that.

That way you can have the same codebase in UAT/testing and production without worrying about negatively impacting production. And, once the testing all works, you can just toggle the switch in production to enable it. Then you can remove the switch from the codebase and remove the old code.

Another option is to spin up a “local” instance of the environment that the development staff can all access. It’s a little more work to set up but it also allows the developers to publish more regularly without impacting production at all. Testers can be given access to this environment so the QA can be conducted.

1 reply

Forum|alt.badge.img+7
  • Captain II
  • Answer
  • December 12, 2025

Alas, publishing does impact all tenants to certain degrees. They aren’t as segregated as we’d like. 

What I do when I need to introduce a new feature that we need available in one tenant, but not another, is to create a switch to toggle the new behaviour on and off. I’ll usually append a boolean field to one of the Setup tables but you can make your own for that.

That way you can have the same codebase in UAT/testing and production without worrying about negatively impacting production. And, once the testing all works, you can just toggle the switch in production to enable it. Then you can remove the switch from the codebase and remove the old code.

Another option is to spin up a “local” instance of the environment that the development staff can all access. It’s a little more work to set up but it also allows the developers to publish more regularly without impacting production at all. Testers can be given access to this environment so the QA can be conducted.