In Salesforce, ensuring the right data is collected often means marking certain fields as required. But there’s more than one way to do it, and each method works differently depending on how users or systems create or update records.
This guide breaks down the different ways to make a field required, where to set them up, and when each option makes the most sense.
Page Layout
Fields are needed during manual data entry but may not exist during data loads or integrations, such as a lead’s phone number for sales reps.
Where to Set: Object Manager > Page Layout
UI Impact: Red asterisk appears immediately
System Impact: API and external systems can still insert or update records without supplying the field.
Lightning Record Page (Dynamic Forms)
You want more flexibility than standard page layouts—such as showing and requiring a field only when specific criteria are met (e.g., when a lead’s status becomes “Qualified”).
Where to Set: Lightning App Builder > Field Component or Field Section
UI Impact: Red asterisk appears before saving
System Impact: Calls from APIs or integrations are not affected by page-level requirements
Global Actions
Global Actions have independent layouts. Users can bypass the requirement via quick create actions if you mark a field required in the page layout but not in the Global Action layout.
Where to Set: Object Manager > Global Actions > Layout
UI Impact: Asterisk appears in the quick action modal
Use When: You need consistency across all user entry points, including quick actions like “Log a Call” or “New Task.”
Field-Level Requirement (Schema-Level)
This is the most stringent method. When a field is marked as required at the schema level, no manual, automated, or integrated interface can bypass the rule.
Where to Set: Object Manager > Field Settings
UI Impact: Asterisk across all interfaces
System Impact: Enforced across UI, API, Flows, Apex, and imports
Use When: The field must always contain data, regardless of how the record is created or updated.
Caution: Use this for business-critical fields only. Changing a required field back to optional can be complex, especially in production environments.
Validation Rule
Validation Rules allow for conditional logic. You can require a field only when another field meets a specific value—for example, requiring “Industry” only when “Account Type” is “Customer.”
Where to Set: Object Manager > Select Object > Validation Rules
UI Impact: No asterisk; user sees error only after attempting to save
System Impact: Enforced across UI and API (unless exclusions apply)
Use When: The field is required based on conditions or when you want to display custom error messages.
Tip: Carefully test your validation rules. Poor design can block Flows, integrations, or imports.
Salesforce Flows
Flows and Apex give you the highest level of control. You can enforce field completion based on external data, time-based conditions, or cross-object logic.
Where to Set: Flows (Screen or Record-Triggered) or Apex Triggers
UI Impact: Custom—depends on how you handle errors
System Impact: Fully enforceable with complex conditions
Use When: Requirements exceed what validation rules can handle or when logic must span across multiple objects.
Conclusion
There are several ways to make a field required in Salesforce, and each fits a different need. Use Page Layouts and Dynamic Forms when working with the user interface, and Validation Rules or Flows when you need more control.
For strict data rules, go with field-level settings or Apex. Picking the right method helps you collect the right data without blocking users or automation.
