+ Start a Discussion
JPSeaburyJPSeabury 

Adding field dependency in scratch org isn't captured as a change in source

New to DX Projects, and trying to incorporate what I believe is a simple change:

GOAL / OBJECTIVE:
Add a dependent picklist (Loss_Reason__c) to the OpportunityStage Standard Value Set, using SFDX as the package deployment method (rather than ANT Migration Tool). 

The fields (Loss_Reason__c and OpportunityStage) already exist in production, but they have no field dependency association with them. I can certainly add that dependency in Production, but I'm trying to avoid that by using this system change as my first DX Project.

I've enabled DevHub on my produciton org, created a scratch org, and a package.xml that retreives these two fields down from production. 

I've created a scratch org and pushed these two fields into it. I then logged into the sracth org, created the field dependency via Setup, selected which Loss Reason fields were associated with specific OpportunityStage picklist values, etc. Saved changes in the scratch org, and then from VS Code typed:

sfdx force:source:status

Got back:
=== Source Status
No results found

Why is the force:source:status not recognizing that I've made changes in the scratch org that are not present in my local environment?

Is it possible to use SFDX for this example (creating / managing field dependcy on standard and custom fields)?

 
Best Answer chosen by JPSeabury
JPSeaburyJPSeabury

That's good, out-of-the-box thinking, Anudeep. H/t to David Reed who also gave this idea when I echo'd this issue over on the Salesforce Stackoverflow community (which I ended up using successfully):

===============

One alternate approach, for situations like this one where Source Tracking is missing subtle changes you've enacted in the org, is to ask SFDX explicitly to retrieve the involved entity rather than relying on Source Tracking.

You can do that with the sfdx force:source:retrieve command, which takes a -m parameter with a specification of what metadata you'd like to pull. It does retrieve in source format.

Here, it looks like what you'd want is simply to do sfdx force:source:retrieve -m CustomObject:Opportunity.

===============

All Answers

JPSeaburyJPSeabury

I think I found an answer on this Salesforce StackExchange community: SFDX source pull field dependencies (https://salesforce.stackexchange.com/questions/197176/sfdx-source-pull-field-dependencies)

So the solution is to make a change to the object itself. I could do that easily if it were a custom object (adding a description of the object, or something similar), but is there any way to change a standard object (like Opportunity)?  ¯\_(ツ)_/¯

AnudeepAnudeep (Salesforce Developers) 
Hi, 

I'm not sure if it's a known bug or not (probably it is), but a workaround is to make any change to your field (Usually modify the description by adding or removing a period) and then pull the change down. Field dependency changes don't seem to be picked up on their own, but they do get picked up with the field's other metadata is updated. You might want to get in touch with Salesforce Support if you want to clarify. Thank You!

Anudeep
JPSeaburyJPSeabury

That's good, out-of-the-box thinking, Anudeep. H/t to David Reed who also gave this idea when I echo'd this issue over on the Salesforce Stackoverflow community (which I ended up using successfully):

===============

One alternate approach, for situations like this one where Source Tracking is missing subtle changes you've enacted in the org, is to ask SFDX explicitly to retrieve the involved entity rather than relying on Source Tracking.

You can do that with the sfdx force:source:retrieve command, which takes a -m parameter with a specification of what metadata you'd like to pull. It does retrieve in source format.

Here, it looks like what you'd want is simply to do sfdx force:source:retrieve -m CustomObject:Opportunity.

===============

This was selected as the best answer