There is --validatedeployrequestid or -q flag for force:mdapi:deploy
-q, --validateddeployrequestid=validateddeployrequestid request ID of the validated deployment to run a Quick Deploy
To run quick deploy of a recently validated package, use -q with the validated ID.
sfdx force:mdapi:deploy -q <validationRequestId> -w -1
The place to look is the Metadata API Developer Guide, in the Metadata Types section.
Note on terminology: these are not Custom Metadata Types. Custom Metadata Types are a specific Metadata API entity. CustomObject, for example, is a built-in Metadata API entity.
In short, yes, you're on a fool's errand.
The general rule is that you can't package any settings that would allow granting 'system' permissions. That is, permissions that affect more than just the objects/schema that your package contains.
For example, you can't package CRUD/FLS on Standard Objects and you can't grant System Permissions like ModifyAllData ...
The versioned FlowDefinition object is no longer recommended as of API 44.0, in favor of the unversioned Flow, which is the point at which behavior around Flow versions changed in the Metadata API.
Using API version 43.0 or prior to retrieve FlowDefinition should return the original versioned files.
I'm not aware of such an API, or any other way of extending standard metadata like this. I think you might be forced into:
Storing the values you require as some Custom Metadata Type, with a 'Key' field that holds the Object and Field API names for querying.
Storing the values in some global utility class, with each JSON string being a value in a Map of <...
The metadata API isn't necessary for getting report information. In apex, there is the Reports and Dashboards API.
String reportId = [SELECT Id FROM Report WHERE ... ].Id;
Reports.ReportMetadata metadata = Reports.ReportManager.describeReport(reportId)....
If you want to use APIs (to keep this very simple) you can:
Create a folder using ContentFolder
You can then create a Document and give it the Folder ID
However if you are trying to do this programmatically - I assume you mean via Apex?
In which case you can create these via Apex (there are a couple of ways to do this, here is an example of using Connect ...
If I understood correctly, this happens because the business process includes all the picklist values for the LeadStatus standard picklist. It ignores the fact that they are enabled or not. The business process metadata lists the fields as the PicklistValue type, but it does not include the isActive attribute of the values (this attribute is included on the ...