Try Serpent Free

How to fix INVALID_FIELD_FOR_INSERT_UPDATE in Salesforce deployments

The deployment tries to write to a field that is not writable, such as a formula field or one the running user cannot edit.

Surfaces during: compile-time or runtime DML, most often inside an Apex test

What it means

INVALID_FIELD_FOR_INSERT_UPDATE means a DML operation, usually inside an Apex test, tried to set a value on a field that cannot be written directly. This happens with formula fields, roll-up summaries, and system fields, and also when Field-Level Security marks a field read-only for the profile running the operation.

For genuinely non-writable fields like formulas, Apex catches this at compile time if the SObject literal syntax is used; for Field-Level Security restrictions, it only surfaces at runtime, since the same code can succeed for one profile and fail for another.

Diagnosis

Common causes

Writing to a formula or roll-up field
Test data factory code sets a value directly on a field that is actually calculated, so the platform rejects the write.
Field-Level Security marks the field read-only
The profile or permission set running the deployment does not have edit access to the field being written.
Field type changed to a calculated field
A field that used to be editable was converted to a formula field, but code that writes to it directly was never updated.

The fix

  1. Remove the direct write
    Delete the line of test setup code that assigns a value to the formula, roll-up, or system field.
  2. Grant edit access if the field should be writable
    Update Field-Level Security on the profile or permission set used for deployment if the field is genuinely meant to be editable.
  3. Audit field type changes
    After converting any field to a formula, search the codebase for direct DML writes to it and remove them.
    grep -rn "Amount_Rollup__c\s*=" force-app/main/default/classes/
In practice

How Serpent prevents this

Serpent AI flags Field-Level Security mismatches between environments during preflight review, before they surface as a runtime failure. See the Salesforce deployment error library.

Metadata and data in one deployment flow in Serpent

Prevention

Search the codebase before converting any field to a formula
Grep Apex and Flow for direct writes to a field before its type is changed, and clean them up as part of the same deployment.
Keep test-data factories in sync with Field-Level Security changes
Whenever a field's FLS changes for the deployment or test-running profile, review test setup code that writes to that field.
Prefer schema-driven test factories over hardcoded field lists
Build test data through a factory that reads writable fields from describe results, so a field-type change fails loudly and early rather than silently in production.
Common questions

INVALID_FIELD_FOR_INSERT_UPDATE, answered

Why did this only start happening after a recent deployment?
Check whether a field was recently converted to a formula or roll-up summary. Code that used to write to it directly will fail from that point forward.
Does this error apply to system fields like CreatedDate?
Yes. System-managed fields like CreatedDate, LastModifiedDate, and Id can't be written directly in ordinary DML; a small set of them can only be set through special API options like createable audit fields, which most orgs don't enable.
Does 'without sharing' or 'with sharing' affect this error?
No. Sharing keywords control record visibility, not field-level writability; a formula field is non-writable regardless of the Apex class's sharing mode.

Start free. No credit card, no install, no commitment.

Set up in under 15 minutes. No DevOps hire needed.

Curious about faster shipping before you dive in? Let's talk

Commitment free!