using vscode to fix reports that break from configuration changes

changes to configuration, like updating picklist values, can easily mess up salesforce reports, which is a perennial problem for yours truly. i think sometime in the middle ages i dealt with this using eclipse but only vague memories remain.

working today on using vscode to deal with this…first I needed to get all reports locally.

this post on dev forum suggested a nifty package generator extension

I used that extension to generate the package. check the “report” metadata type and it crunched through all 6k(!) reports we have and created a package.xml file


then i could easily retrieve all reports by right clicking on the package.xml file and selecting “retreive source from org using manifest” in vscode!


i then used find/replace in folder to update the old picklist value to the new one! but if I then use force:source:push it deploys all reports, not just the modified ones.

I found a way to only deploy modified reports : use sfdx force:source:tracking:reset before doing the find/replace to on reports

per the multiple warnings thrown all over this command, THIS CAN BE DANGEROUS AND YOU SHOULD BE CAREFUL

this command ‘resets’ the source tracking so it doesnt see any changes (like all the reports we just pulled in). but in this case that is just what i want.

after running the command, do find/replace in the reports folder in vscode to replace the old value with the new value.

then run force:source:push and only the reports that were just modified will be pushed (bc we had reset source tracking)!

however, if any of the reports you modified have other errors (invalid picklist values, deleted record types, etc)…those will throw an error and nix your deployment…


but i simply copied those reports into .forceignore and did force:source:push again and SUCCESS!


you can copy/paste the errors from terminal in vscode into excel and split text to columns to get the report names. you also can get the errors in deployment status in the target org

format for forceignore is (no folder name)


so that gets the reports to a sandbox, but how do you get them to prod (without deploying all reports, or manually selecting them in a change set…)

you may be able to use force:source:push and set -username to your production org. i dont think that will run tests and the deployment will fail, but have not tested yet.

i was testing out the new devops center functionality, and that worked like a charm.

list of steps


Now read this

Replacement for “Stay in Touch” using Flows

captains log : star date april 2018 – check out this new post that allows using the lightning runtime on a flow in a visualforce page in a site. New and improved y'all. Original post is below: The native Salesforce stay-in-touch... Continue →