Do not export readonly fields such as formulas in data tree export plan files

[pozil]

sf data tree export retrieves value of readonly fields (formulas, composite fields, system fields...) and stores them in the generated plans file but the plan can't be imported back because formula fields are always readonly.

Current behavior as of v2.55.6:

sf data tree export retrieves value of formula fields and stores them in plan files.
When importing the plan file with sf data tree import, you get errors such as:

{
    "statusCode": "INVALID_FIELD_FOR_INSERT_UPDATE",
    "message": "Unable to create/update fields: xxx. Please check the security settings of this field and verify that it is read/write for your profile or permission set.",
    "fields": [
        "xxxx"
    ]
}

Expected behavior:

sf data tree export ignores formula fields or other readonly fields present in the query and doesn't store them in plan files.

[mshanemc]

wouldn't you have to query them for them to show up in the export?

The issue becomes "oh, is this a export query for re-import" or "you just wanted to do a query and get a lot of plan files" to use for something else besides import tree, where you do want the values of those fields.

[mshanemc]

so maybe it would make more sense for import to strip them (knowing they'll fail) rather than export?

[pozil]

Yes, I accidentally included a few of these in my export query. It would be nice if the import would ignore them and maybe just output a warning?

The problem that I faced (and I assume that I'm not the only/first one to follow this process) is that I spent some time tweaking my plan by manually editing it to add relationships before trying to import it and then face the issue. In the end it would have taken more time to regenerate a new plan with a clean query vs cleaning the JSON files to remove the readonly fields.

[VivekMChawla]

@pozil - Could you elaborate on your manual edits to add relationships?

Ideally, there should be a simple pipeline to refresh an exported data tree. I'd like to understand if there's an opportunity to improve that part of the process for your use case.

[pozil]

@VivekMChawla the reason why I had to edit relationships manually is because SOQL queries can be nested but it only work in one direction when working with Master-details relationships: from child to parent.

Take this schema:

I can grab contacts and guest reviews in a single query but I can't continue and grab experiences within the same query:

SELECT id, lastname, firstname, ...,
  (SELECT id, ... FROM Guest_Review__r)
FROM Contact

What I ended up doing is generating separate plans to cover the remaining objects. Then, I manually merged the plan files into a single master plan by editing references.