Two people open the same request. One changes its due date. The other changes its title, then saves a form that still contains the old date. What should your app keep?
Use this rehearsal to decide before sharing a team app. Overskill lets you describe the app you want to build; a useful description includes what happens when someone saves an outdated form. You will leave with a field-by-field resolution, an editable app requirement and a two-session test for the resulting app.
This is an optional exercise in Part 4, Test the app you built. Start with the client portal guide if you are still deciding which records clients and staff need. The rehearsal below runs two editor forms in one tab with fictional data. Its Save buttons change only that local example. It does not connect to your app or prove how a generated app handles simultaneous requests.
Watch an outdated form try to restore an old date
The fictional request is R-014, “Workshop landing page,” due November 10, 2026, owned by Alex. Editors A and B both open version 7.
Choose Load independent changes. A's draft moves the due date to November 12; B's draft changes the title to “Kite workshop landing page.” Neither change has been saved yet.
- Choose Save A locally. The current record becomes version 8, due November 12. B still has the version-7 form.
- Choose Try B's full save. It is rejected. B's proposed title stays in the form, and the current date stays November 12.
- Choose Compare B with current. Read all three rows before saving a resolution.
Scroll horizontally to compare all columns.
| Field | B originally opened | Current after A saved | B proposes | Resolved value |
|---|---|---|---|---|
| Title | Workshop landing page | Workshop landing page | Kite workshop landing page | Kite workshop landing page |
| Due date | 2026-11-10 | 2026-11-12 | 2026-11-10 | 2026-11-12 |
| Owner | Alex | Alex | Alex | Alex |
B did not intentionally change the date. Keeping A's date and B's title preserves both independent edits. Save resolved B locally then creates version 9. The comparison itself never saves anything.
Before that local save, Show resolution JSON lets you inspect the same proposal used by Download and Copy. It names the record, the compared version and every field decision. It is a test artifact, not a saved server record. Saving or changing relevant inputs clears the old export.
Use four rules, in order
Compare three values: the original value B opened, the current value, and B's proposed value.
| First matching condition | Decision |
|---|---|
| Current and proposed are equal | Keep their agreed value. |
| Proposed still equals original | Keep the current value. B did not change this field. |
| Current still equals original | Take B's proposed change. |
| Both changed differently | Leave a conflict for a person to resolve. |
An empty string explicitly clears a field in this exercise. It is a value to compare, not permission to fill in something else. Missing fields and null are rejected. Dates are date-only values; the aid does not schedule reminders or interpret a time zone.
The rules cover exactly a title, due date and owner label. They do not decide how to combine attachments, comments, rich text or a list of people. Keep those decisions separate in your app brief.
Make competing edits visible
Choose Load competing due dates, then save A and compare B. A wants November 12; B wants November 14. Both differ from the original November 10.
The date row now requires Keep current or Use B's proposed value. Neither the resolved Save nor export is available until you choose. Choosing November 14 is a deliberate decision to replace A's date; the tool does not guess which person has the better reason. The brief should state who may make that decision in your workflow.
If both editors choose November 12, the first rule finds agreement. There is no conflict to resolve. Choosing the same result and choosing different results are separate test cases.
A resolution can become outdated too
Repeat the independent-change example through Compare, but do not save B's resolution. Reopen A from current, change its owner label to Sam, then save A. The current record is now version 9.
The old version-8 proposal is cleared. B's title and original form are retained. Compare again: the new proposal targets version 9 and contains B's title, November 12 and Sam. Saving that resolution creates version 10.
A real app needs to check again when it writes, even if the user just reviewed a conflict screen. Another person could save between comparison and confirmation. Ask for the version check and write to happen together on the server; a browser-only check cannot establish that protection.
Test permission changes and deletion
Prepare a comparison, then turn off Simulate B having edit permission. B's simulated save, comparison and export must stop. A matching version cannot grant access. The sample remains visible because the switch is an exercise control, not authentication.
Reset and try Delete the fictional current record. Neither editor's stale form may recreate it. Reset explicitly starts a new fictional rehearsal; a real app needs its own deliberate restore policy.
Use the private-record access guide to specify who can read, edit, list, search and export each workspace. This page's local model checks consistency between its own values. It does not authenticate a supplied original snapshot, enforce real permissions or test server transactions.
Carry the example into a build and a real test
Before saving a resolved local comparison, choose Prepare brief from this resolution. Review its workspace permissions and exact example, then edit it for your app. Keep the record identity, expected version, three-field rules and stale-save behavior explicit. Choose Start build beside the editable brief to carry that text into Overskill, continuing through sign-in if needed. Building uses your account's usual access and credits. Later rehearsal changes do not silently rewrite your prepared brief; review it before starting.
For a renovation project portal, inspect Quarry's template page and its current starting options before choosing a template. The public preview inspected on October 8, 2026 showed a phase board and estimated job examples. Shared editing, version checks and permission enforcement were not tested there. Treat those as requirements to implement and verify in your app.
Download the two-editor worksheet for an editable test script and answer key. Download the example resolution for the exact independent-change proposal shown above. The JSON has no import function and no connection to a live record.
Run the worksheet in two authorized test sessions using fictional data. Record the accepted version and values after each save; confirm rejected attempts preserve the other person's work and the unsaved draft. Then test a third change, revoked permission, deletion and two saves racing from the same version. Mark each untested case openly. Use the interruption guide for the separate return, retry and navigation checks.