I have an app that sends outbound messages via workflow rules. When a customer makes a copy of their org as a sandbox I start getting outbound messages for that org as well. Is there a best practice approach to solving this?

We're considering making a custom setting with the original org ID and adding a check to make sure the outbound message is originating from the right org. That feels a bit clunky. I'm surprised that I haven't found a more standard solution to what I assume is a relatively common problem.

We are not admins on the org - either the original or sandbox - we are 3rd party developers. So there is no admin level stuff we can do on either org. We don't want to have to rely on some other admin remembering to do something on their end because we can get flooded with useless API calls when they forget and it can be hard to get them to fix it at that point.

We'd prefer a solution where the API calls never come to us in the first place.

2 Answers 2


The outbound message includes the OrganizationId as a parameter. Before I discovered that, I built a formula field on the object using the $organization global variable to pass the org ID, which works as well.

Then you can configure your integration to determine which org it's coming from and process appropriately.

I sent a simple outbound message that just includes the record ID to requestb.in, and it looks as follows. You can see that OrganizationId is included by default.

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <notifications xmlns="http://soap.sforce.com/2005/09/outbound">
   <SessionId xsi:nil="true"/>
    <sObject xsi:type="sf:Error_Log__c" xmlns:sf="urn:sobject.enterprise.soap.sforce.com">

However, the only way to prevent the message from being sent would be to include $organization ID in the workflow rule criteria.

I recall from some previous testing that Salesforce might automatically update the rule criteria when it moves to sandbox. I know it sounds bizarre, but i do remember something along those lines happening, will do some more testing and update my answer when I have the details.

UPDATE: Hard-coding $Organization.Id in the workflow rule and deploying between environments worked properly. I cannot recall the exact issue I ran into previously alluded to above, but if you only want the rule to fire only in production, hard-coding $organization.Id into the rule itself will work using the 15 character Id (the 18 character version will not trigger the rule).

Adding Org Id to Rule Criteria

UPDATE 2 re-re-reading the thread, i see that you are looking for ways to be control this w out any admin access.

The answer to the following thread looks like it would be helpful. There is a field called IsSandbox on Organization that you can hit to determine if it's coming from prod or sandbox. However, from my testing it doesn't look like you can hit it in workflow criteria, only via apex, so you would need to consider if this might work or not.

Can we determine if the Salesforce instance is production org or a Sandbox org?

  • This might work. We currently create the workflow rules dynamically through the API. How are you hard coding the Org Id in the workflow rule? Apr 13, 2016 at 17:14
  • You can reference the $organization global variable directly in the workflow criteria. So you should be able to get the org ID and then put that as a criteria in the rule. Have zero experience w dynamically creating workflows but since it's feasible via the ui dont imagine it would be an issue
    – gorav
    Apr 13, 2016 at 22:40
  • 1
    Thanks, I added an image to your answer to make it clear for anyone in the future as to how to do this. Apr 14, 2016 at 20:21
  • Thanks that is most helpful. I'm living off my phone as I'm in low power mode for a while to deal w some stuff...
    – gorav
    Apr 14, 2016 at 22:21
  • Also never thought that org ID would be the same as any other ID and have 15/18 version. Thanks for including that.
    – gorav
    Apr 14, 2016 at 22:25

The correct way to handle this is on the receiving endpoint - where you do have control. Evaluation of the Org ID is essential in ensuring security and not processing requests from Sandbox environments for a production endpoint. The first thing the receiving endpoint should be doing is validating the 18 digit Org Id included in the request matches the expected value.

You must log in to answer this question.

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