You may come across this Salesforce validation error when deploying changes to a target Salesforce org - "Not available for deploy for this organization".

An example of this error in our app can look like this:

Based on our observations and investigated cases, there are a number of different metadata types that have returned this error, such as (but not necessarily limited to):

​ ApexClass, Audience, Bot, BotSettings, DataDotComSettings, EinsteinDealInsightSettings, FieldServiceSettings, EmailTemplate, LiveMessageSettings, ManagedTopics, Network, OrderManagementSettings, PresenceDeclineReason, PresenceUserConfig, ServiceChannel, ServicePresenceStatus, QueueRoutingConfig, UserAccessPolicy, WaveApplication, WaveDataflow, WaveDashboard, WaveLens, WaveReceipe.
​

During org to org deployments via Compare an deploy, as we have highlighted in Gearset's blog post Salesforce deployments that just work, this error may be related to features in the source org that aren't enabled in the target org.
​
If you're making a Git (branch) to org deployment, it's likely you're missing some user permissions in the target org. These permissions may be necessary for a successful deployment of the metadata item that's throwing the error.

This error can happen when your Salesforce user has Salesforce Integration license assigned.

This license generally allows Gearset users to validate and deploy standard or custom objects and fields.
​
However, Salesforce Integration license isn't enough for deploying most of other metadata types (e.g. new or updated permissions, or custom items like Flows or Apex) - and it is likely to result in one of these two errors:
- "Insufficient access rights on cross-reference id"
- "not available for deploy for this organization"
​
More information on best practices and workarounds in our blog post.

There are a few things you can check when you come across this error:

​1. Verify if your Salesforce deployment user have all the necessary permissions to deploy the metadata item to the target org.

Note:

​2. If you're not able to confirm what user permission(s) may be needed to deploy the change, we recommend to check this with admins managing the org permissions, as they may be the most suited people to help.
​
​3. Are both compared environments on the same API version? Differences in metadata API versions between source and target orgs may cause validation errors.
​
Try setting your metadata filter's API version to Default (highest common version), and re-run the comparison:

4. If component(s) failing the validation are related to or are part of a managed package, check if the same version of managed package is installed in the source and target environment.
​
To check if your managed package component is on the same version source and target, try re-runing the comparison with Package version item handling option being set to Hide items when different (as on image below).
​
If item gets retrieved, that means package versions are the same, and therefore validation is more likely to succeed.