API version mismatch between org and xml getting created during workflow run

[Mukul01coder]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Workflow Configuration

Discussion Details

Hi Community,
My target org in on API 66 but even when I am using sed or xmlstarlet to explicitly define the api version after fetching the target orgs API, the package. Xml getting generated during workflow run is 63... I am unable to get this fixed, Can anyone help who faced this issue or anyone having any idea how to resolve this.

[Mukul01coder]

I am trying to deploy flows but the flows contains new properties as per latest API version but when I am trying to deploy it via Github Actions it throws errors like properties not supported in particular API version whereas the target org is on same API but the package.xml which gets created during run goes to version 63 because of which it's not working... Any possible solution for this

[Gitious]

The reason sed/xmlstarlet aren't sticking is that the Salesforce CLI regenerates package.xml from your project config when it builds the deploy payload, so any edit you make in an earlier step gets overwritten before the deploy runs. This is a Salesforce DX issue rather than a GitHub Actions one.

A few things to check in order.

First, open sfdx-project.json in your repo and look at sourceApiVersion. That value is what stamps the generated package.xml. If it says "63.0", change it to "66.0" and commit. This is the most common cause and the most reliable fix, because there's a known historical issue where the --api-version flag on the legacy sfdx force:source:deploy doesn't always override sourceApiVersion.

Second, on the deploy command itself, pass --api-version 66.0 explicitly. For example: sf project deploy start --api-version 66.0 --source-dir force-app (or the legacy sfdx force:source:deploy --apiversion 66.0 if you're still on the older CLI). Per the Salesforce CLI docs, command-line flags take priority over project config, so this is a good belt-and-suspenders backup once sourceApiVersion is fixed.

Third, make sure the CLI itself is recent. An older CLI version can default to an older API. Add a step like npm install -g @salesforce/cli@latest before the deploy and run sf --version to confirm.

Fourth, if you're using sfdx-git-delta to build the package, it has its own -a, --api-version flag that defaults to sourceApiVersion in sfdx-project.json, so pass 66.0 there too. Otherwise the delta package is generated at its own default.

Fifth, for flows specifically, the individual .flow-meta.xml files contain their own <apiVersion> element. If those still say 63.0, the deploy will throw "The field apiVersion can't be [X]" even with a v66 package.xml. Either bump them in source or retrieve the flows fresh from the org with sf project retrieve start --metadata Flow --api-version 66.0.

Quick way to verify: after your build step, before the deploy step, cat package.xml and one of the modified flow files. If the version isn't 66.0 at that point, you know it's sourceApiVersion or the CLI default doing it, not the deploy command.

If after fixing sfdx-project.json and adding the --api-version flag the deploy still complains about properties not supported, that's no longer a packaging problem. It means the target org doesn't actually have those v66 properties enabled yet, even if the org is on API 66, since some flow features require specific release toggles to be on.