I came across what seems like a very odd behavior today:

There is a legacy workflow rule in my org that hardcodes in the production org ID in order to only run in the production environment. (The Rule Criteria formula includes $Organization.Id = '00DZ000000XXXXX')

When a new sandbox is created, the Rule Criteria formula changes, swapping out the production org ID for the sandbox one.

Is this intended behavior, and if so, is it documented anywhere? While hardcoding these IDs is clearly a bad practice, I feel that this could be very misleading.


Yes, this is intentional, and yes, this is documented.

Sandbox and production orgs always have unique org IDs. The sandbox copy engine creates an org as part of each creation and refresh request. So, the org ID of your sandbox changes each time your sandbox is refreshed. Salesforce inserts the new value in any place the org ID is used, such as text values and metadata.

I don't believe there's a way to correctly detect if an org is a sandbox within a workflow rule. You'd probably want to build a solution involving a Custom Setting that identifies if the rule should run, and set up a SandboxPostCopy script to force proper behavior.


I call a feature like this "instance awareness". It's really important when dealing with integrations.... you don't want to pollute production with sandbox data.

I setup a hierarchy custom setting, at the org default level, with both the 15 character and the 18 character production org Ids. It's been working for years, regardless of how often we refresh our sandboxes.

Custom Setting Definition

You can use the 15 character value in formulas. This example only fires in the Production Org.

Formula Example

There's a repo with more details here

  • 1
    The custom setting approach is the only declarative option that I can find that works. Hierarchy custom settings are accessible in workflow rules and visual workflow, so you can compare whether $Organization.Id = $Setup.MyCustomSetting.ProdOrgID and proceed appropriately. – gorav Jun 25 '19 at 15:59
  • visual workflow can query the Organization object, to hit isSandbox. so no need to evaluate the ID itself, and therefore safe. really ought to have been accessible as a global variable, but should be ok in future. – gorav Dec 2 '20 at 21:35
  • @gorav That's great. This approach is kind of obsolete these days, and in new implementations we are looking at that isSandbox property. Incidentally, scratch orgs have a value of true for isSandbox – John Thompson Dec 3 '20 at 17:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.