Making a Field Required in Salesforce: Complete Guide
In Salesforce, ensuring data integrity is crucial. One of the most effective ways to achieve this is by making certain fields required, so that users must provide a value before saving a record. Salesforce provides multiple mechanisms to enforce field requirement, ranging from declarative options (point-and-click) to programmatic approaches (Apex and validation rules).
This guide explores all the ways you can make a field required, including their use cases, advantages, and limitations.
1. Mark Field as Required at the Field Level
The simplest way to make a field required is by configuring it at the field definition.
Steps:
- Go to Setup → Object Manager → [Object] → Fields & Relationships.
- Click on the field you want to make required.
- Check the box “Required”.
- Save the changes.
✅ Advantages:
- Easy and declarative.
- Works across all record creation interfaces (standard page layout, API inserts).
⚠ Limitations:
- Cannot make a field conditionally required (e.g., only required if another field has a certain value).
- Overrides layout-level requirement checks.
2. Mark Field as Required on Page Layout
You can make a field required only on a specific page layout.
Steps:
- Go to Setup → Object Manager → [Object] → Page Layouts.
- Select a page layout to edit.
- Click on the field, select Properties, and check “Required”.
- Save the layout.
✅ Advantages:
- Flexible: different layouts can have different required fields.
- Useful when you want to make a field required only for certain user profiles or processes.
⚠ Limitations:
- Works only in UI (Lightning or Classic). API or Apex inserts can bypass this.
- Conditional requirements need additional validation rules.
3. Use Validation Rules
Validation rules allow you to enforce complex conditions for required fields.
Example:
Suppose you want the Secondary_Email__c field to be required only if Has_Secondary_Email__c is checked:
AND( Has_Secondary_Email__c = TRUE, ISBLANK(Secondary_Email__c) )
- If the formula evaluates to TRUE, Salesforce prevents the record from saving and displays an error message.
✅ Advantages:
- Conditional requirement enforcement.
- Works both in UI and API.
- Provides custom error messages to guide users.
⚠ Limitations:
- Formula must be carefully written to avoid false positives.
- Cannot pre-populate default values automatically (you can combine with flows or triggers for that).
4. Use Apex Triggers
Apex triggers give you full control over when and how a field should be required.
Example Trigger:
trigger ContactTrigger on Contact (before insert, before update) {
for (Contact c : Trigger.new) {
if (c.Has_Secondary_Email__c && String.isBlank(c.Secondary_Email__c)) {
c.addError(‘Secondary Email is required if Has Secondary Email is checked.’);
}
}
}
✅ Advantages:
- Can enforce requirement on any complex business logic, including cross-object conditions.
- Works for bulk operations.
⚠ Limitations:
- Requires Apex coding skills.
- Maintenance can be harder than declarative solutions.
- Overuse can impact performance if not bulkified.
5. Use Flow or Process Builder
Salesforce Flows (Screen Flows and Record-Triggered Flows) allow you to enforce requirements dynamically.
Steps:
- Go to Setup → Flows.
- Create a Screen Flow or Record-Triggered Flow.
- Add a Decision element to check if the field is blank.
- If blank, either:
- Display an error message on the screen, or
- Prevent record creation/update (Record-Triggered Flow with Fault path).
✅ Advantages:
- Declarative solution with conditional logic.
- Can handle both UI and automation scenarios.
⚠ Limitations:
- Requires users to interact with flow screens for UI enforcement.
- API updates may bypass unless record-triggered flows are used.
6. Required Fields in Managed Packages or Managed Fields
If using managed packages, some fields might already be required by the package.
- You cannot uncheck “Required” for managed package fields.
- This ensures that business logic in the package is not broken.
7. Combination Approaches
In real-world Salesforce orgs, it’s common to combine multiple approaches:
- Field-level required for fields that are always mandatory.
- Page layout required for UI-specific mandatory fields.
- Validation rules or flows for conditional requirements.
- Triggers for complex multi-object validation or integration scenarios.
Best Practices
- Prefer declarative options first (field-level or page layout required).
- Use validation rules for conditional requirements — they are easy to maintain and user-friendly.
- Use Apex triggers only when declarative options are insufficient.
- Document all required fields to avoid confusion for admins and developers.
- Always test both UI and API to ensure required logic is enforced consistently.
Summary Table
Method | Declarative | Conditional | API-safe | Pros | Cons |
Field-level Required | ✅ | ❌ | ✅ | Simple, global | Cannot be conditional |
Page Layout Required | ✅ | ❌ | ❌ | Flexible per layout | Bypassed by API |
Validation Rule | ✅ | ✅ | ✅ | Custom conditions | Needs formula knowledge |
Apex Trigger | ❌ | ✅ | ✅ | Full control | Requires coding, maintainability |
Flow / Process Builder | ✅ | ✅ | ✅ (if record-triggered) | Declarative, conditional | Complexity can increase |
Conclusion
Making a field required is a fundamental way to ensure data quality in Salesforce. The choice of method depends on:
- Whether the requirement is always mandatory or conditional
- Whether the enforcement should happen in UI, API, or automation
- Complexity of business logic and maintainability