What Is an sObject?

Account acc = new Account();
Contact con = new Contact();
Course_Enrollment__c enrollment = new Course_Enrollment__c();

sObject genericRecord1 = acc;         // valid — Account IS an sObject
sObject genericRecord2 = con;         // valid — Contact IS an sObject
sObject genericRecord3 = enrollment;  // valid — even custom objects ARE sObjects

This is Module 11's polymorphism ("is-a" relationships) applied at the platform level — every single Salesforce object, standard or custom, is fundamentally an sObject. Account, Contact, and Course_Enrollment__c all share this common base type.

public void logRecordId(sObject record) {
    System.debug('Record Id: ' + record.Id);
}

logRecordId(new Account(Name = 'Acme Logistics'));
logRecordId(new Contact(LastName = 'Dlamini'));

Because Id exists on every sObject, logRecordId can accept any kind of record — Account, Contact, or any custom object — without needing a separate overloaded version for each type. This is exactly Module 11's polymorphism, letting one method work uniformly across many concrete record types.

sObject record = new Account(Name = 'Acme Logistics');
// record.Industry;  // compile error — sObject alone doesn't know about Industry
Account acc = (Account) record;
System.debug(acc.Industry); // fine, now typed specifically

An sObject variable only exposes what's common to every record (like Id) — accessing a field specific to Account, like Industry, requires casting back to the specific type first. This mirrors the trade-off from Module 11's polymorphism lesson: generality in exchange for giving up type-specific access until you cast back down.