Force export options
Closed this issue · 10 comments
Can the export functionality provide command line options to exclude certain metadata types?
We have large number of reports and dashboards in our org and the export function fails with too many files limit.
What about using force fetch? You can provide a package.xml file with the metadata you want to grab.
Just ran into this issue this morning as well - I'd counter that one of the issues might be that it might not be simple to tell what's causing the file limit issue. Is there a way to break these calls up to prevent hitting the limit?
Excluding metadata types would be pretty easy.
Splitting up the export would be more difficult because of how Profiles are retrieved. The Profiles would need to be retrieved with each batch of metadata, then the xml for each profile would need to be merged together in order to end up with the full profile.
What about using force fetch? You can provide a package.xml file with the metadata you want to grab.
Justification for the ability to exclude certain meta-data types: I use "force export" to download the meta-data and then archive it. Unfortunately, if the "force export" fails, I get nothing. I don't have a need to export the reports/dashboards/documents for archiving purposes.
I use "force export" to download the meta-data and then archive it.
Same here. I work with different client environments and we find the CLI tool a quick way to run a backup of metadata prior to a deployment, or just as a backup practice during development. This got to the point where I messed around last week with trying to build a Powershell script to fetch different metadata types automatically and independently if force export failed, but it's pretty slow and not efficient.
Me three - we use a script to both backup metadata and track changes to it over time via git, which uses "force export" to fetch the metadata, retries when it fails (perhaps due to a large number of documents), and then deletes the documents dir because it's massive and not really useful for our purposes anyway.
Thanks @KThompso for letting me know that we can get specific types using force fetch + package.xml, I didn't realise that, it'll come in handy!
@mwanchap My reason for using fetch instead of export is that export may pull down some sensitive data that you don't want stored in a git repository. I suggest generating an initial package.xml with export and then removing anything that may contain sensitive data.
Out of curiosity, are you able to track the user who last modified the metadata? I believe that information is available either via the metadata or the tooling API, but I'm not certain how to achieve it.
Git, not Github ;) It lives in a private Azure Devops repository that only our admins have access to. We mostly use it to find where custom fields are referenced if we need to rename them etc.
We'd also love to be able to track who last modified the metadata, but the only place I've seen this kind of thing is in the "Setup Audit Trail" section, which I thought was only accessible via the UI, but I just realised there's been an API for it since 2016: http://releasenotes.docs.salesforce.com/en-us/winter16/release-notes/rn_api_objects_new.htm#sat
I'm thinking this should be implemented like force export -x Report -x CustomMetadata, which would export everything except Reports and Custom Metadata.