What “required” can mean in Salesforce
There are several layers that can make a field necessary:
These layers can produce similar user-facing failures. A request that succeeds for an administrator can still fail for an integration user because the two users have different permissions, record-type defaults, or automation paths.
| Layer | What to inspect |
|---|
| Object schema | Fields that Salesforce requires for creation |
| Field definition | Required custom field setting |
| Record type | Default values and process-specific configuration |
| Field-level security | Whether the API user can see or edit the field |
| Validation rule | A conditional requirement expressed as a formula |
| Flow or Apex | Automation that rejects or changes the record during save |
Capture the exact failing field
Do not keep only the HTTP status. Store the object, API version, user or integration identity, record type, request correlation ID, and redacted request body. Salesforce often returns the missing field in the error message or an error array. Preserve that field name exactly, including the `__c` suffix for custom fields.
Example REST create shape:
Use the API version supported by your org and client. If an automation tool such as n8n, Zapier, or Make is sending the request, inspect the final serialized body rather than the form before its mapping step.
{
"Name": "Example customer",
"Industry": "Technology"
}
Check permissions before adding a value
An API user needs access to the object and field. Field-level security can make a field invisible or non-editable even when an administrator sees it. If the error says a required field is missing but the integration cannot write that field, the fix is an access or schema decision, not a retry.
Compare the integration user’s profile and permission sets with the successful test user. Also confirm that the request is sent to the intended org and record type. A sandbox and production org can have different fields, defaults, and deployments.
Record types and defaults
A record type can select a business process, page layout, picklist availability, and default values. Do not assume a default shown in the UI will be applied to every API path. Send an explicit record type ID when the business process requires it, and verify that the integration user can use that record type.
For a controlled test, create one record with the same record type used in production. Compare the result with an administrator-created record. If the admin record receives a default and the API record does not, inspect the record type, automation, and API request rather than copying the final database value blindly.
Validation rules, Flow, and Apex
Some requirements are conditional: a field is required only when a status, country, or record type has a particular value. Validation rules can reject a payload even when every ordinary schema-required field is present. Record-triggered flows and Apex triggers can also perform additional checks or clear a value before the transaction completes.
Ask the Salesforce administrator to review the save order and automation executed for the target object. Capture the exact rule or automation error. Do not disable a validation rule in production merely to make an import pass; decide whether the integration should provide the missing business value or use a dedicated integration path.
Null, empty string, and omission are different
These values are not interchangeable:
Test create and update separately. An update that clears a field may have different behavior from a create that never supplies it. For imports, reject rows with no valid source value before sending them and report the source row number.
| Input | Typical meaning |
|---|
| Field omitted | Let Salesforce or automation apply its normal behavior |
| `null` | Clear where permitted, or fail if the field is required |
| `""` | Empty text, invalid value, or a failed required check |
| Valid value | Satisfy the requirement if permissions and rules allow it |
A deterministic recovery sequence
First reproduce one failure with the same integration user. Next record the object, record type, and final JSON. Fetch metadata and identify fields that are createable and required. Check field-level security. Review validation rules and save-time automation. Then send a minimal payload with one known-good value and add business fields incrementally.
If the minimal request still fails, compare orgs, API versions, record type, and user permissions. If the minimal request succeeds, the defect is in mapping, a conditional rule, or one of the added fields. Keep the successful request as a regression fixture.
Production safeguards
Validate required fields at the integration boundary, but keep Salesforce as the final authority because metadata can change. Store a versioned field contract with object, field API name, record type, source mapping, and blank-value policy. Put unresolved rows in a dead-letter queue with a redacted error and replay only after correction.
For bulk loads, preserve an external ID or source key so a corrected row can be upserted safely. Monitor missing-field failures by object and release. A sudden increase usually indicates a metadata deployment, permission change, new record type, or mapper regression.
The trap: sending `null` or an empty string to every missing field. That can hide the real mapping defect and still cannot satisfy a required field.
A release fixture for required fields
Keep one create fixture per object and record type with the smallest known-good payload. Add a second fixture that intentionally omits the required field and assert that the error identifies the expected field. Run both under the real integration user after metadata or permission changes. This prevents a UI-only test from falsely declaring an API create path healthy.
Where these facts come from
