Fixing It by Hand Without Losing It Tomorrow: A Precedence Sheet for Manual Overrides
A staff member corrects a value by hand. The next sync runs, sees a different value in the source, and silently puts the old one back. Everyone concludes the fix did not work, and the correction is repeated every week.
This article proposes a manual override precedence sheet: a short written rule set, plus a record attached to each correction, that tells a sync what to do. It is a conditional design. Adapt it to what your storage and sync tooling really allow.
What an override record holds
For each overridden field, store:
- The field and the record it belongs to.
- The corrected value.
- Who made it and a short reason.
- The source value at the moment of correction (the base).
- An expiry date, or an explicit statement that none applies.
The base is the key. It lets a sync tell the difference between a source that has not changed and a source that has moved on.
The precedence sheet
| Situation at sync time | Behaviour |
|---|---|
| Override active, incoming value equals the base | Keep the override, change nothing |
| Override active, incoming value differs from the base | Keep the override, raise a conflict for review |
| Override expired | Apply the incoming value, mark the override released |
| Override active, field missing from the incoming data | Keep the override, no conflict |
| Override record lacks a base | Treat as a conflict and ask a person to restate it |
Two cautions. A conflict must not overwrite either side on its own. And a person resolving it should choose to renew, release, or adopt the new source value, with the choice recorded.
Worked hypothetical
An invented supplier list has a field for lead time in days. Staff corrected three records by hand:
- Record R1: override 5, base 7, no expiry.
- Record R2: override 5, base 7, no expiry.
- Record R3: override 4, base 6, expired yesterday.
The next sync brings:
- R1 incoming 7. It equals the base, so the override stays and nothing is raised.
- R2 incoming 9. It differs from the base, so the override stays and a conflict is raised.
- R3 incoming 6. The override is expired, so 6 is applied and the override is marked released.
Totals: 3 records, 2 overrides still active, 1 released, 1 conflict raised. Check that these numbers add up before trusting a run report: active 2 plus released 1 equals 3.
Why not just lock the field
A permanent lock hides the source forever. A field that is locked for a year may hold a value nobody remembers choosing. Expiry, or at least a periodic review date, keeps manual fixes from becoming invisible policy. Where a field should always be manual, say so in the sheet and remove it from the sync entirely instead of using an override.
Stop conditions
Stop and ask a person if:
- Conflicts on one field exceed what can be reviewed in a normal sitting, which hints the source is changing in bulk.
- An override appears for a field you did not list as eligible.
- A sync would apply a value over an override because of an error rather than the sheet.
Proposed acceptance tests
These are proposals for a test copy, and none has been run.
- Run the three records above through a sync. Expect the 2 active, 1 released, 1 conflict outcome.
- Run the same sync twice. Expect the second run to raise no new conflict for R2 beyond the one already open.
- Remove the field from incoming data for R1. Expect the override to stay.
- Create an override with no base. Expect a conflict, not a silent apply.
- Check that the screen shows the override, the source value, and the expiry together.
Limits
This protects a field only when the sync reads the sheet's rules before writing. Other writers, such as imports or scripts, need the same check. Describe the rule as a layered constraint with review, not a guarantee that no value is ever lost.