I'm working towards moving an existing managed package over to the SFDX CLI metadata format.

Part of the application is a Connected App which forms a core part of a SSO process to an external system via Canvas. So I can't really leave it out of the scratch orgs without taking out other large sections of functionality.

I've found in the past that it isn't possible to include the oauthConfig > consumerKey in the SFDX CLI metadata as that key is unique to the org it was generated in.

After excluding the consumer key from the .connectedApp-meta.xml file I can successfully push the source to a new scratch org.

However, now when I try an push an unrelated change to a Visualforce page to the scratch org I'm getting an "invalid cross reference id" error on the connectedApp. I'm not sure why the CLI is trying to push the connected app again. I haven't made any changes to it. Maybe it has detected the new consumer key that was generated on first push?

I did find a similar question with relation to profiles - Salesforce DX: Pushing profiles gives 'invalid cross reference id'. The suggestion there was to make an arbitrary change to the metadata in Salesforce and then pull it down again.

Trying that, I get the following error:

A general data error occurred with your entries

enter image description here

Any ideas on how to get the connected app into the Scratch org and then being able to work with the org afterwards?

For a Second-Generation managed package there appears to be a special ceremony to go through that results in referencing the Connected App by the namespace (db_0110_ns4) and the connected app name (A_Connected_App). E.g.

<ConnectedApp xmlns="http://soap.sforce.com/2006/04/metadata">
    <label>A Connected App</label>

I attempted this with my first generation package, but the CLI push came back with the error:

Contact email needs to be in a valid email format

Which suggests it was still looking for the <contactEmail> element in the metadata file rather than referencing the connected app in the existing package version.

  • 1
    What specific challenges are you having though? Connected Apps aren't meant to be migrated this way. Your Canvas App has to depend on a specific instance of a Connected App, as it will have a unique Client ID. While I haven't had a chance to test this extensively (i.e. I have no specific answer), I believe your approach is definitely not correct. Perhaps you should rephrase this as a question about resolving challenges that arise from not including the Connected App.
    – sfdcfox
    Apr 17, 2019 at 3:59
  • 1
    Good point. Even after I deploy the Connected App without the consumer key it isn't going to be any use unless I reconfigure the external system. For a short life org like a scratch org it probably isn't worth the effort. So is the expectation that we just won't do any development that depends on a Connected App with SFDX against scratch orgs. That seems limiting. Apr 18, 2019 at 2:11
  • No, it should automatically "install" upon first use. Give it a try and let me know ow it goes.
    – sfdcfox
    Apr 18, 2019 at 2:25

1 Answer 1


It's odd. I tried to do a simpler repo and couldn't reproduce the problem. Under the ideal situation a SFDX force:source:push will only create the connected app with the first push. Any subsequent push commands will ignore it.

However, something is occurring that causes SFDX to try and push it again. In that case the underlying metadata deploy fails with the invalid cross reference id message. That is expected as the metadata file doesn't have the ID that was created with the first push to the Scratch org.

At this stage the easiest workaround I've found is to add the path to the connected app metadata to the .forceignore file.

You must log in to answer this question.

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