Test a record edit that saves behind a loading overlay

The contract this flow keeps

The flow is built around the saving state and a reload, both of which most record tests skip.

• The starting value - 240 employees, captured before the edit.
• Two fields change - a number and a picklist, which save through different paths.
• The overlay is observed - the button shows a saving state before the record returns to read-only.
• The values survive a reload - which is the only proof the save reached storage.

Without the reload this test proves the page updated its own state, which is exactly what an optimistic UI does whether or not the save succeeded. The reload is the whole point.

The objective in plain English

The saving state is asserted rather than waited out, which means a save that completes instantly and one that never starts are distinguishable.

---
mode: testing
url: https://my-testing-repo-main.vercel.app/salesforce-clone-app/accounts?reset=true
max_steps: 45
tags: [salesforce, crm, records]
---

# Salesfource 28.4: Record edit through the overlay

Catalog objective: edit an account field and save through the loading overlay.
Key assertion: the saved value persists after a reload.

## Open the record for editing
Verify the "Northwind Labs" account shows "Employees" of "240", then click "Edit" on it.

## Change a field
Replace "Employees" with "310" and select "Manufacturing" in "Industry".

## Save through the overlay
Click "Save" and verify the button shows a saving state before the record returns to its read-only view.

## Verify the value persisted after a reload
Verify "Employees" now reads "310" and "Industry" reads "Manufacturing", then reload https://my-testing-repo-main.vercel.app/salesforce-clone-app/accounts and verify both values are still there.

Both a numeric field and a picklist are changed because they commit through different code paths, and a save that handles one and drops the other is a realistic failure.

Assertion by assertion

A baseline, an edit, a save and a reload.

A reload costs a few seconds and converts an optimistic render into a proven write. On a record edit it is the difference between testing the UI and testing the save.

Putting it in CI

kane-cli testmd run tests/salesforce/record-edit-overlay_test.md

Add a validation failure on save, since a rejected save that leaves the form looking saved is the worst version of this flow.

Overlays and async saves are where selector-based suites spend most of their maintenance. How live page assertions work explains the alternative, and the run speed work is relevant if you plan a large CRM suite.