I want to be able to query, insert and update records of a Sandbox from a Scratch org, only during the development phase. I know that scratch orgs are meant to be populated with just a little amount of data that would be used for testing or UAT, but in this case, all the data I need is located/persisted in custom objects originated from a managed package from other vendors (it means that I can't write SOQL queries for that objects because it would not even compile in my scratch org).

I prepared a diagram to help you understand what I want to accomplish:

enter image description here

I'm almost 100% sure that I can do it all via Salesforce APIs (not sure about updating or inserting, or any other limitations). However, I would like to avoid using explicit callouts and if statements all over my code. So I came up with the very basic idea of creating a class that would encapsulate this logic. Something like:

public class MyDatabaseHelper {
    public static List<SObject> query(String statement){
        String env = getEnvInAnyWay();
        if(env == 'sandboxA'){
            // Use native Database class to query if inside Sandbox
            return Database.query(statement);
        } else {
            // If outside, use HTTP callouts for Salesforce API
            return MyCalloutHelper.makeAPICalloutWithStatment(statement);

But I'm not convinced that it is the best solution, because even without starting to implement it this way, I know that I would lose, for example, the SOQL binding support because Database.query() call will not be inside the context where the variables are.

Does anyone know how can I do it in a better way?

  • So do you want execute a SOQL statement in your other sandbox org with variable binding? – Bryan Anderson Nov 22 '19 at 15:47
  • Not exactly... variable binding is just a thing that I can give up. What I really want is to have one single way to access data from a sandbox/dev org while working on a scratch org. And if I put this code in a managed package, and install it on that sandbox it would also work. – Sergio Nov 22 '19 at 16:29
  • 1
    Just from top of my head -- callout behaves in different way as SOQL, so it would not be possible to make a callout to external system after DML, which could be potentially huge deal – kurunve Nov 22 '19 at 16:36
  • @kurunve I was talking about calling out the Query API: developer.salesforce.com/docs/atlas.en-us.api_rest.meta/… – Sergio Nov 22 '19 at 16:56

I think this solution is very unlikely to work. For one thing, you're going to break all of your unit test classes in a scratch org context, or else build complicated mocks or conditional logic to supply this data to your unit tests.

Instead, I'd recommend working on build automation that will seed your scratch orgs with a standardized data set sourced from your primary sandbox. CumulusCI can do this for you (disclaimer: I'm on the team that builds this free, open source product).

Alternately, if the record volume is quite low, you could create them in each new scratch org via Anonymous Apex execution.

You can install the managed package in your scratch orgs by getting its 04t Id and using sfdx force:package:install, or simply getting the namespace and version number and deploying an InstalledPackage Metadata API entity. That will result in the package being installed in the scratch org.

| improve this answer | |
  • Yes, that is one of the reasons why I think it is very far from the best approach. I thought of bringing some data into my org, but all I need is not in native objects, but, instead, in custom objects created by other vendor's managed package. As I am unable to install it in my orgs, I can't have any data. – Sergio Nov 22 '19 at 16:53
  • 1
    @Sergio why can't you install that package in your scratch orgs? (CumulusCI should be able to handle that for you too, or you can do it with SFDX) – David Reed Nov 22 '19 at 16:55
  • It belongs to other company and it is huge (not sure if it's a problem at all, but it has lots lots lots of metadata). And I don't have the installation url nor it is available in App Exchange. – Sergio Nov 22 '19 at 16:58
  • 1
    @Sergio Just grab the namespace and version number and you can install it. I'll edit my answer. – David Reed Nov 22 '19 at 17:06
  • David, thanks for the suggestion! I'll definitely try it. As I mentioned, this package seems to be huge and has lots of metadata. Do you foresee any problem after installing it in the scratch org? – Sergio Nov 22 '19 at 17:18

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.