Controlled contact corrections
Correct the contact.
Keep the original.
Review the current email and phone, replace them deliberately and retain the accepted before-and-after record. A changed contact does not rewrite an earlier repair’s captured name or a saved estimate’s customer reference.
Early access · manager-owned email and phone corrections
Check the current record
Read the selected customer’s recorded contacts.
The name supplies read-only contextReview the replacement
Choose each new contact or explicitly clear it.
Explain the reason before recordingRetain the accepted original
Before, after, reason and recorded attribution.
Separate from the current profile and working draftAn explanation of record handling, not identity verification, contact consent or a notification result.
A correction belongs to one deliberately selected record.
A jeweler receiving an estate ring may recognize a customer’s name but still need to check which stored record belongs in the conversation. The customer directory searches recorded names in the active location. Review the chosen current summary before opening contact corrections in its own tab. There is no automatic first-customer choice, inline merge or inference that two matching names identify the same person.
The separate workspace keeps an open registration, buying draft or repair intake undisturbed. Its current source contains the selected record’s name as read-only context, email and phone. This correction does not change names, partial identification fields, risk or verification flags, addresses, customer notes or consent records.
An owner, admin or manager can record a correction. The interface begins without a proposed replacement or a checked approval. Use the checked contact explicitly if it is a useful starting point, then review both contact fields and the reason. Reading a current profile is different from deciding that it should be replaced.
The email typo and the replacement phone are two decisions.
Imagine a hypothetical customer with a mistyped email and an old phone number. A manager reads the current selected profile, chooses the checked contacts as a starting point and fixes the email. They enter the replacement phone supplied for this record, then explain the correction in plain language. The proposed values remain separate from the current values until the reviewed command is accepted.
Both email and phone are part of the replacement. If the email is correct and only the phone needs changing, retain the intended email deliberately. If the phone is no longer known, choose the explicit clear-to-unknown action instead of leaving an ambiguous blank. The app does not invent a number, select an alternative from another record or send a confirmation message.
Review the before-and-after display with the selected name and your reason. The accepted record retains the original entered contacts, proposed normalized replacements, recording time and operator attribution. This is a recorded correction, not proof that the caller owns the number, can receive email or is the person named in the profile.
Unknown, empty and invalid historical text deserve different treatment.
An older customer record may contain no phone, an empty string, whitespace or a malformed email. The before record preserves what was actually stored. A correction does not tidy that earlier text into a more convenient history or claim that a previously malformed address was valid.
The new replacement uses bounded single-line contact fields, with a valid email format when an email is supplied. Entering a well-formed address does not verify delivery or consent. Clearing a contact records an explicit unknown value; it is not a zero, a successful unsubscribe or deletion of all past occurrences.
Changing your draft does not refresh the live source behind it. Refresh the current contact separately, read any difference and adopt that checked basis explicitly. Typed email, phone and reason remain available for review. If another manager changed the record first, the stale correction must be reviewed again rather than automatically overwriting the newer contacts.
Current contact details do not rewrite a saved repair.
Suppose the estate ring already has a repair custody record that captured the customer’s name at intake. A contact correction changes the supported current email and phone only. It does not rewrite the intake identity, recorded repair events, a saved estimate’s original customer facts or the original registration receipt.
The correction workspace separates the checked current profile, working replacement, confirmed original correction and explicitly selected saved history. A returned original is evidence of that accepted command; it is not silently promoted to the current contact if a later correction already exists. Refresh the current record for the current answer.
Managers can read the recent twenty small correction summaries and open an older authorized saved correction directly. A selected historical before-and-after record retains its own recorded context. No first history record is selected automatically, and the history is not a tool for reverting a profile or reissuing old documents.
A lost response is not permission to start another correction.
If the connection fails after Save, the correction may already have been accepted. The mounted page retains the exact original request while the operator edits the next proposal or reads a different saved correction. Check that original first. A missing confirmation does not prove no change occurred, and the app does not silently create a fresh replacement command.
Recovery remains separate from the current profile. A later contact change can make the original correction historical without making it untrue. Keep the page open: this increment supplies mounted-page recovery, not offline or hard-reload persistence. Late results from another location, customer or permission state do not replace the visible scoped evidence.
Evaluate with an email typo, a phone-only change, explicit clearing, an invalid legacy contact and two customers sharing a number. Confirm that current correction history and old repair facts remain distinct. Name correction policy, merges, verification, contact consent, messages, retention and a full customer portal remain separate work. Read the current boundaries and use the repair custody guide for actual handover responsibilities.