How do you prevent outbound messages from sandbox orgs as a 3rd party developer?

Question

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.

Answer 1

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">
 <soapenv:Body>
  <notifications xmlns="http://soap.sforce.com/2005/09/outbound">
   <OrganizationId>00DL000000487RxMAI</OrganizationId>
   <ActionId>04kL0000000Cbr1IAC</ActionId>
   <SessionId xsi:nil="true"/>
   <EnterpriseUrl>https://cs8.salesforce.com/services/Soap/c/36.0/00DL000000487Rx</EnterpriseUrl>
   <PartnerUrl>https://cs8.salesforce.com/services/Soap/u/36.0/00DL000000487Rx</PartnerUrl>
   <Notification>
    <Id>04lL000000A8lgyIAB</Id>
    <sObject xsi:type="sf:Error_Log__c" xmlns:sf="urn:sobject.enterprise.soap.sforce.com">
     <sf:Id>a8zL00000004pgFIAQ</sf:Id>
    </sObject>
   </Notification>
  </notifications>
 </soapenv:Body>
</soapenv:Envelope>

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).

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?

Answer 2

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.