0

I am working in an environment where my Dev sandbox is API 53.0 and my destination QA sandbox is API 52.0. I use the metadata api to deploy changes but I am running into some frustrating issues when trying to deploy to an org that is a version behind.

I am trying to push Profile changes to QA but there are properties of the profiles that only exist in my Dev org because of new features/installed packages introduced in 53.0. These new Profile properties try to deploy to QA and error out because they don't exist.

My current work around is to retrieve metadata, CRTL+F that property in the metadata config files, delete it, and re-deploy. This works but it is a major pain and it is preventing less technical team members from being able to move their changes to QA without my assistance.

Is there a deployment setting I can adjust to have it ignore properties that don't exist in the destination org? I run into this issue of my Dev sandboxes being ahead of my destination sandboxes a lot so a long term solution to this would be appreciated. Thanks in advance!

Improve this question
4
  • do you have specific examples of what's "new" in the profile that is throwing errors? I presume you're referring to any new objects/fields out of your control? Also, how are you deploying/retrieving in your process? You can typically set the API (in package.xml or sfdx-project.json) to be whatever you'd like (ex. 52) so you retrieve/deploy metadata as it was on that version - however, new objects would obviously still lead to new objectpermissions on profiles as your org's schema is technically different at that point.
    – Kris Goncalves
    Sep 17, 2021 at 15:57
  • It is the ViewDeveloperName property on Profile. Looks like this was introduced from the Sales Insights managed package, which was installed from 53.0 update (I presume because the update timelines align to when it was installed). I have the package.xml set to 52.0 but these properties are still getting pulled in the retrieve from Dev.
    – Rory
    Sep 17, 2021 at 16:04
  • 1
    It's a new permission. Doesn't appear you have much option here as it's exposed/pulled in all versions. It'll be marked as true on all standard profiles. Doesn't help you now, but going forward, I generally try to avoid this situation (if you have static dev and QA sandboxes) by refreshing any sandboxes after the cutoff date to stay on the current version. To test the new version, it'd be a "new" org not vital to the release process.
    – Kris Goncalves
    Sep 17, 2021 at 16:36
  • Thank you so much for this information, Kris. The cutoff date link is very helpful and should help prevent such issues moving forward! Stinks that there is no quick fix for now but this will save me a lot of time in the future. Thanks again.
    – Rory
    Sep 17, 2021 at 16:43

2 Answers 2

Reset to default
2

A better way of dealing with this in modern development is to use Scratch Orgs and Salesforce DX. This way, you can always develop code and metadata in the version you desire, rather than dealing with the timings involved with Sandbox refreshes. You can even use Unlocked Packages (for customers/consultants/etc) or Second-Generation Managed Packaging (mostly for ISVs) to deploy your changes to any org. You can use the release property of your Scratch Org Configuration File to control if you're creating a previous version org or a preview version org (available only during release windows). This way, you don't end up with any surprises. Also, you can use sfdx force:source:pull and sfdx force:source:push to retrieve and deploy changes to an org without specifically tracking which changes you've made (for Source Tracked orgs only, though). In short, if you're still suffering from these sorts of issues, you probably want to look into SFDX. If your Dev org doesn't have a namespace, you can also enable Dev Hub to keep track of your Scratch Orgs in that org. It has a limited capacity for the number of orgs you can create daily and keep at once, as well as version creations, but if you're using your own Developer Edition org, it should suffice for your use case.

Improve this answer
2

Generally, API versioning handles a lot of "differences".

As an example, metadata types may have new attributes or even change the structure. This should cause no issue if you still set your API to the current version in your commands/release steps (retrieve/deploy)as it's version-specific.

There are sometimes things that are new that are there for all versions. Profiles are definitely the big culprit here. New standard objects can be added which will add a new ObjectPermission reference or, in your specific example, there's a new UserPermission like ViewDeveloperName that is exposed/returned in all versions.

You don't have any options other than doing what you've noted:

  • Identify the "new" thing that is consistently returned giving you an error
  • Make it a point to search and remove that reference before every deployment

Going forward, however, I'd recommend avoiding this situation and forcing your sandboxes to stay on the current version to avoid this pain. This assumes your release process relies on certain static sandboxes (ex. Dev --> QA --> production). Having them all on the same version will obviously make things smooth and you can do smoke testing for the newest version in a separate sandbox.

To do the above, Salesforce always provides a list of which sandbox instances are on preview (upgrade automatically) or non-preview (no upgrade, stay on current version). There's a certain window (~a week) where refreshes will be routed to preview instances and after this window refreshes will be non-preview. This is typically noted in help documents, but you can use the Sandbox Preview Guide which explains all of this when you pass your instances you're interested in as shown below:

enter image description here

Improve this answer
3
  • having been a recent victim of this; it would appear that at least when winter 22 came out, which introduced new CustomObject like Seller, that a MD API retrieve at V52 (Summer 21) with wildcards still fetched the new V53 objects
    – cropredy
    Sep 17, 2021 at 22:12
  • 1
    @cropredy This is why I prefer force:source:push/force:source:pull and Scratch Orgs. So much easier to predict what you'll retrieve and deploy when you use SFDX (plus Unlocked Packages for deploys to production).
    – sfdcfox
    Sep 18, 2021 at 2:13
  • 1
    100% agree on using Scratch Orgs being the goal to strive for with development. However, there's still many valid reasons to have static sandboxes for a lot of companies (ex. custom integrations and company testing tracks, training environments, etc).
    – Kris Goncalves
    Sep 18, 2021 at 20:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.