04.01.01 — Standard vs Custom Objects: What QA Must Understand

💡 The Problem: “Standard” Does Not Mean “Safe”

In Salesforce, everything starts with Objects.
They are the foundation of the entire data model and the primary surface where business logic, automation, and permissions collide.

From a QA perspective, we work mainly with two object types:

• Standard Objects (e.g. Account, Contact, Opportunity, Case)
• Custom Objects (any object ending with __c)

A very common — and very dangerous — assumption is:

“This is a standard object, Salesforce already handles it, so it’s safe.”

This assumption is wrong.

Standard Objects are often more complex and risk-prone than custom ones because they carry deep, implicit platform behavior that is not visible in configuration screens and cannot be removed.

This lesson explains:

• how Standard and Custom Objects differ from a QA perspective
• what risks are hidden inside “standard” functionality
• how those differences should influence your test design

⚙️ Critical Differences and Their Testing Impact

Understanding the nature of the object you are testing directly affects what you test, how deep you go, and where you expect regressions.

Area	Standard Objects	Custom Objects	QA Implication
Deletion behavior	Often restricted, archived, or soft-deleted	Fully deletable unless constrained	Verify what really happens on delete (blocked, recycled, cascaded)
Key system fields	Often immutable (OwnerId, RecordTypeId)	Fully configurable	Test logic that relies on standard fields — they behave consistently but power many automations
API names	Fixed and stable	Defined by project	Lower rename risk, higher dependency risk for integrations
Sharing model	Complex defaults, often broad access	Private by default	Standard objects require careful security and sharing verification
Automation footprint	Pre-existing background logic	Starts empty	Higher regression risk on standard objects

The key takeaway:

Standard Objects come with behavior you didn’t build — but still need to test.

🔍 Testing Standard Objects: Finding Invisible Logic

Standard Objects often contain platform-level logic that is not visible in Flow Builder, Process Builder, or Setup screens.

Example: Lead Conversion

Testing Lead Conversion is never just about the Lead.

You are implicitly testing:

• Account creation
• Contact creation
• Opportunity creation
• Field mappings between all three

QA focus areas:

• Is Lead.Status correctly updated to Converted?
• Are custom fields mapped correctly to Account and Contact?
• Are record types and ownership assigned as expected?

One user action → multiple object mutations.

Example: Case Ownership and Assignment Rules

Case ownership may change automatically based on:

• Email replies
• Assignment Rules
• Escalation Rules
• Background platform logic

QA focus areas:

• Does custom assignment logic override standard behavior?
• Are ownership changes predictable and traceable?
• Does automation behave consistently across channels (UI vs Email)?

🧱 Testing Custom Objects: Enforcing Data Integrity

Custom Objects do not come with hidden behavior — but they also do not come with safety nets.

Everything must be explicitly tested.

Data Structure

Each field must be validated for:

• correct data type
• required vs optional behavior
• default values
• validation rules

Relationships

You must explicitly test:

• Master–Detail vs Lookup behavior
• Referential integrity
• Cascade delete and roll-up summaries

UI & Navigation

Custom Objects must be tested for:

• Lightning App visibility
• Custom Tab configuration
• Page layout consistency across profiles

🚀 Practical QA Heuristics

Ask the Design Question

When testing a Custom Object, always ask:

Why does this object exist?

• If it represents a transactional concept (e.g. Order, Request)
  → prioritize automation, integration, and negative paths.
• If it represents a hierarchical or planning structure
  → focus on relationships, roll-ups, and data consistency.

Sandbox Reality Check

Do not rely on a Developer Sandbox when testing Standard Objects that may include:

• legacy Apex
• historical automation
• complex sharing models

Use Partial or Full Sandboxes when:

• data volume matters
• ownership logic matters
• performance or governor limits may be involved

✅ Summary: Complexity Lives in Different Places

• Standard Objects hide complexity inside the platform
  → test background behavior, sharing defaults, and implicit automation.
• Custom Objects expose complexity in configuration
  → test structure, constraints, and relationships explicitly.

From a QA perspective, neither is “simpler”.
They are complex in different ways, and your test design must reflect that.

Understanding where Salesforce hides complexity is the first step to testing it effectively.