Fix Guides

How to Fix "Required Fields Are Missing" Errors in Salesforce

Step-by-step fix guide with AI-powered diagnosis from BuildForce.

Salesforce enforces "required" in three independent places that don't always agree: field-definition required (blocks UI AND API), page-layout required (UI only), and validation rules (blocks whatever triggers the rule). "Required fields are missing" from an integration, a Data Loader job, or a Flow almost always means you're hitting field-definition-required or a validation rule — not the page-layout star you can see in the UI.

The Three Enforcement Layers

  • Field-definition required — set on the field itself in Object Manager. Enforced everywhere: UI, REST/Bulk API, Data Loader, Flow, Apex.
  • Page-layout required — the red asterisk you assign per layout. UI-only; an API call or Data Loader job can insert a record without it.
  • Validation rule — enforced wherever the rule's criteria fire, which can be conditional and doesn't require the field to always be populated.

Common Triggers

  • A field is required on the page layout but not at the field-definition level — feels required in the UI, but an API call, Data Loader job, or Flow-created record skips right past it.
  • A Flow's Create Records element doesn't map a value for a field that IS required at the definition level, because the flow author never saw it on the input screen.
  • Record-type-to-page-layout mismatch — required on the layout for Record Type A, not required (or absent) on the layout for Record Type B.
  • Data Loader / bulk import CSV missing a mapped column for a field that's required at the definition level.
  • A validation rule using ISBLANK()/ISNULL() enforces conditional requiredness that isn't visible from the page layout at all.

How to Fix It — Step by Step

  1. 1. Read the exact field API names in the error. 'Required fields are missing: [Field1, Field2]' names the specific fields. Don't assume — confirm exactly which fields Salesforce is complaining about before changing anything.
  2. 2. Check whether it's field-definition-required or layout-required. Setup → Object Manager → [Object] → Fields & Relationships → the field → is 'Required' checked at the field-definition level? If not, this is only a page-layout requirement, and something else (the API, Data Loader, or Flow) is hitting the real gap.
  3. 3. Fix the source if it's an integration or bulk import. If the failure is coming from an API call, middleware integration, or a Data Loader job, fix the source system's payload or column mapping to always populate the field — don't make the field optional just to make the symptom go away if the business genuinely needs the value.
  4. 4. Fix the automation if it's Flow or Process Builder. Add the missing field to the Create/Update Records element, including a sensible default (a formula, a hardcoded value, or a Get Records lookup) for fields that were never shown on any screen the flow author saw.
  5. 5. Audit record-type-to-layout assignments. Setup → Object Manager → [Object] → Page Layouts → Page Layout Assignment. Confirm every record type's assigned layout marks the field consistently, so behavior doesn't silently differ by record type.
  6. 6. Use a validation rule for conditional requirements. If the field should only be required in specific situations (a status, a record type, a stage), replace blanket field-definition-required with a targeted validation rule using ISBLANK()/ISNULL() combined with the condition.
  7. 7. Re-test through every entry point. UI, REST/Bulk API, Data Loader, Flow, and Apex can each behave differently depending on which layer of 'required' they respect. Test the fix through the specific path that actually failed, not just the UI.

This Error Is a Symptom, Not the Root Cause

A field that's only required at the page-layout level is easy to miss across every object it applies to — and every integration, Flow, or import that writes to those objects inherits the same gap. Run BuildForce's free health check to see how your org's overall setup compares to similar companies, then connect your org so BuildForce can compare field-definition, page-layout, and record-type requiredness across every object instead of waiting for the next integration to find the mismatch.

How BuildForce Prevents This

FAQ

Why did this pass when I tested in the UI but fail from our integration?

Because the field is required only at the page-layout level, not at the field-definition level. Page-layout-required is enforced only by the UI form itself — it puts a red asterisk on the field and blocks Save, but it does nothing to an API call, a Data Loader job, or a Flow-created record. Field-definition-required (Object Manager → Fields & Relationships → the field → Required checkbox) is enforced everywhere, including every API path.

Does marking a field required on the page layout also enforce it via API?

No. Page-layout-required is UI-only. If you need a field to be genuinely required for every creation path — UI, REST/Bulk API, Data Loader, Flow, Apex — it must be required at the field-definition level, or enforced by a validation rule that fires regardless of entry point.

How do I make a field required only in certain situations?

Use a validation rule instead of field-definition-required. For example: AND(ISPICKVAL(Status, "Closed Won"), ISBLANK(TEXT(Close_Reason__c))) blocks save only when the condition applies, instead of blanket-requiring the field on every record regardless of status.

Why does one record type let me save without this field, and another doesn't?

Page layouts (and therefore page-layout-required fields) are assigned per record type. If Record Type A's layout marks a field required and Record Type B's layout doesn't include that requirement — or omits the field entirely — the same object will behave inconsistently depending on which record type is used. Audit Page Layout Assignment (Setup → Object Manager → [Object] → Page Layouts) to find the mismatch.

Can BuildForce catch page-layout/field-definition mismatches like this?

Yes. BuildForce's health checks compare field-definition requiredness against page-layout requiredness and record-type assignments across your objects, so a field that behaves inconsistently between the UI and your integrations shows up as a finding before an integration fails in production.