4

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.

Improve this question

3 Answers 3

Reset to default
4

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.

Improve this answer
1

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

Improve this answer
3
  • 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
    Commented Jun 25, 2019 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
    Commented Dec 2, 2020 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
    Commented Dec 3, 2020 at 17:10
0

@gorav posted an elegant solution to the lack of $Organizatin.IsSandbox in Flows on his blog: https://goravseth.com/issandbox-in-flow

  • Before your Decision "Add a Get Record" to your Flow, (name it "getOrganization") pinging the Organization Object
  • Then in your Decision have {!getOrganization.IsSandbox} Equals False
Improve this answer

You must log in to answer this question.

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