04.01.02 — Field-Level Testing: Types, Constraints, and Defaults

💡 The Problem: Fields Are Not Just Containers

In Salesforce, a field is not just a place to store data.
Its definition — data type, constraints, and default value — is the first and most important validation layer in the system.

When field-level configuration is wrong or insufficient, teams often try to compensate with:

• Validation Rules
• Flows
• Apex logic

This is backwards.

If field definitions are not tested properly, invalid data reaches automation layers where fixing issues becomes significantly more expensive and risky.

This lesson focuses on field-level testing as the foundation of Salesforce data quality.

⚙️ The Four Dimensions of Field-Level Testing

Every new or modified field should be tested across four critical dimensions.
Skipping any of them creates hidden risk.

1. Data Type Validation (The Domain Constraint)

The data type defines what values are allowed by design.
Testing here ensures that only valid data can ever enter the system.

Data Type	QA Focus	Practical Technique
Number / Currency	Boundary values, negative numbers, decimal precision	Use Boundary Value Analysis (min, max, out-of-range)
Date / DateTime	Date logic, time zones, edge cases	Test leap years, DST changes, automation based on date differences
Text / Picklist	Length limits and value restrictions	Test max length (N-1, N, N+1), restricted vs unrestricted picklists
Email / URL	System-level format validation	Verify Salesforce native validation fires, not custom rules

QA mindset:
If the field accepts invalid data at this level, everything downstream becomes unreliable.

2. Required Flags and Uniqueness Constraints

Required and unique fields must be enforced everywhere, not only in the UI.

Constraint	Test Focus	Expected Behavior
Required (Schema-level)	Save record without value via UI and API	Save should fail consistently
Unique / External ID	Insert duplicate values	Uniqueness violation error

Critical rule:
A constraint that works only in the UI is not a real constraint.

3. Default Values (The Silent Influencer)

Default values often look harmless, but they frequently interfere with automation logic.

Key things to test:

• Is the default value applied correctly on record creation?
• Does automation react to defaulted values or only to changed values?

Common pitfall:
If a Flow runs on ISCHANGED(Status) and the field has a default value, the Flow may not execute on creation — even though the status appears set.

This is a classic source of “why didn’t the Flow run?” defects.

4. Field-Level Security (FLS) & Accessibility

At the field level, security testing is about who can see and change what.

QA must verify:

• Read-only fields are truly non-editable
• Hidden fields are not accessible via indirect actions
• API updates respect FLS constraints

This is especially important when:

• multiple profiles exist
• permission sets are layered
• automation updates fields users cannot edit manually

🚀 Practical QA Techniques

Pro Tip: Always Test Constraints via API

Never trust UI-only behavior.

Use Data Loader or API tools to attempt inserting invalid data.

If invalid data can be inserted via API:

• the field is misconfigured
• automation will eventually break
• reporting and analytics will become unreliable

UI validation ≠ data integrity.

Roll-Up Summary Fields: Special Case

Roll-Up Summary Fields introduce indirect behavior that must be tested explicitly.

QA focus:

• Verify calculation logic (SUM, COUNT, MIN, MAX)
• Test behavior on child create, update, and delete
• Consider data volume and recalculation performance

Large numbers of child records can expose:

• performance issues
• governor limit risks
• delayed or failed recalculations

✅ Summary: Field Integrity Is the First Line of Defense

Field-level testing is not “basic testing”.
It is the foundation that protects the entire system.

By validating:

• data types
• required and unique constraints
• default values
• field accessibility

QA ensures that bad data is stopped before it reaches Flows, Apex, integrations, and reports.

When fields are tested properly, downstream testing becomes simpler, faster, and more reliable.

In Salesforce, clean data starts at the field level — or it never starts at all.