INVALID_TYPE: sObject type 'X' is not supported
Your deployment package references an SObject the target org doesn't have. Either it's a custom object that hasn't been deployed yet, a standard object only included with certain editions, or a feature-gated object the org hasn't enabled.
Also seen asINVALID_TYPE·Cannot find sobject·sObject type is not supported·INVALID_TYPE: sObject type
The deploy refuses because Apex (or a flow, or a layout, etc.) references an SObject the target org has no schema for. The fix depends on which kind of "missing" is at play.
Three flavours of missing
1. Custom object not deployed yet
Your package references MyCustomObject__c. The target org doesn't have it. Fix: include the custom object in the same deploy or a prior one.
The order matters in mixed deploys — the object's .object metadata must be in the package before anything that references it. If you use sf project deploy start with a single source folder, the CLI handles ordering. If you build a package manually, ensure the objects/ folder is fully populated.
2. Edition / license-gated standard object
Some standard objects are only available in certain editions:
| Object | Requires |
|---|---|
ContentVersion, ContentDocument | All editions, but file-API features only on certain |
Quote, QuoteLineItem | Quotes feature must be enabled (Setup → Quotes Settings) |
LiveAgent*, MessagingSession | Service Cloud + relevant feature licences |
Voice* | Service Cloud Voice |
Account.PersonAccount, PersonContact | Person Accounts must be enabled (irreversible — be careful) |
WorkOrder, ServiceAppointment | Field Service installed |
If the target org doesn't have the feature, the deploy can't reference its objects. Either install the feature first, or strip the references from the package for that target.
3. Org-specific deactivated object
Some standard objects can be turned off org-wide. Lead exists by default; an admin can disable Lead Conversion in some workflows. If you reference it, deploy fails until the feature is on.
How to find the reference
The deploy log usually names a file:
Apex Class 'AccountSync.cls': INVALID_TYPE: sObject type 'Quote' is not supported
Open that file. The Quote reference is what's missing. Either deploy Quote to the target (enable Quotes), or remove the reference (replace with a configurable lookup, gate behind Schema.getGlobalDescribe().containsKey('Quote')).
Defensive pattern for cross-edition packages
If you ship a managed package that has to work on Enterprise and Professional Edition, gate the optional features:
public class FeatureGate {
public static Boolean QUOTES_ENABLED =
Schema.getGlobalDescribe().containsKey('Quote');
}
if (FeatureGate.QUOTES_ENABLED) {
// ... reference Quote here ...
}
The Schema.getGlobalDescribe() runs at runtime and tells you what's actually in the org. The reference can compile because the platform allows references via Type-erased calls (Database.query, getSObjectType) but balks at static type references.
Sandboxes and source-tracking weirdness
A sandbox refresh sometimes drops feature licences. After a refresh, deploys that worked yesterday fail with INVALID_TYPE. Fix: re-enable the feature in the refreshed sandbox before deploying.
