We're using SFDX in Azure DevOps for CI.
Our workflow is basically:

  • Dev creates a git branch for feature
  • Dev develops feature in their own sandbox
  • Dev creates PR to merge feature into integration branch
  • On PR approval, Azure pipeline merges dev branch with integration branch and deploys all source items (as defined in manifest\package.xml to integration sandbox (Partial Copy) for testing.

This used to work, but now we are seeing all deployments failing with
An object [object name] of type [type name] was named in package.xml, but was not found in zipped directory
This is happening for every single component (thousands of them) being deployed to the sandbox.

We are using force:source:convert and force:mdapi:deploy for the deployment step.

This started being a problem right after we performed a git revert on integration branch. The revert and subsequent merge were completed successfully, but the deploy failed.

The reason for the revert was that it did not correctly compile the source files. It kept claiming that an external string (custom label) did not exist, even though the CustomLabels.label-meta.xml was part of the deploy.

Running force:source:deploy from my local machine worked.
So it's either an issue with mdapi or Azure.

1 Answer 1


We changed the YAML file on Azure to use force instead of mdapi and that seems to have worked. It may also be a little bit faster since it doesn't need to convert.
As an aside, another developer encountered the same errors while using force from their computer. In that case the issue was caused by a Summer '23 sandbox trying to deploy to a Spring '23 sandbox. It was trying to copy the new gender identity fields (and other related items, like new translation meta-files) to a sandbox that could not accept them.
I suspect that that is what caused our first deploy error, and then things just spun out of control.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .