Files course 03 — Share the right revision and close the review loop

Turn a stored file into a usable handoff by sending the actual item link with a clear request, checking the recipient’s experience and keeping revised uploads distinct from unverified version history.

In this chapter

• Prepare a complete handoff
• Check access and review as different outcomes
• Introduce a revision without losing the original
• Decide what happens to the older draft
• Recover without creating more ambiguity

Prepare a complete handoff

A recipient needs more than “see attached”. Identify the complete filename, intended revision, purpose and requested response. Retrieve the item in its verified folder, open the three-dot menu and choose Copy link. Use the application-supplied locator; do not reconstruct a URL from a name or guessed item identifier. Copying a link and granting access are separate operations. Chapter 2’s saved-audience check should precede a handoff, but it cannot replace the recipient’s own opening check.

A useful request for the practice checklist is: “Please open Workshop-checklist-r01.txt using this link, confirm the r01 marker and review whether the three agenda items are clear. Reply in our agreed conversation with Ready for practice or Changes needed, plus one reason.” Add the real copied link and any genuinely agreed response time. Do not invent a deadline or select an unrelated colleague to complete an exercise.

Choose an authorised conversation and verify its audience before sending. A private file should not be announced in a broad team conversation simply because the link is convenient. Sending the request is another action with its own destination and timing; the Share dialog does not send the complete review instruction for you.

Check access and review as different outcomes

Ask the recipient to use the account and workroom intended by the grant. Confirm the complete filename and internal revision marker, then ask for a substantive content detail. A visible file card, correct filename or “thanks” does not demonstrate that the contents opened. For the workshop example, a reply identifying the second agenda item and giving a readiness decision is more informative than a generic acknowledgement.

Separate these possible results:

• The item cannot be found: verify the actual link, workroom and item identity. A misspelled name is not necessarily an access failure.
• The item is visible but contents will not open: inspect the account, effective rights and any stated viewer or organisation-policy restriction. Visibility and readability are different.
• The correct revision opens but changes are requested: access succeeded; the work is not yet ready. Address the review rather than widening permissions.
• The recipient opens an older revision: resolve the item or link mismatch before accepting their decision as applying to the current draft.
• The recipient confirms the revision and gives the requested decision: the handoff has a useful result. Preserve the decision in the agreed conversation so the next person can understand it.

If opening fails, do not immediately grant Owner or enable “Anyone with the link can access”. Check the intended account, complete item, current location, saved direct and inherited access and the actual message first. A policy-blocked preview is not solved appropriately by bypassing organisational controls. Ask the responsible owner for an approved route.

Introduce a revision without losing the original

Suppose the reviewer asks for clearer preparation instructions. Edit your local practice content to create Workshop-checklist-r02.txt, with r02 inside the first line and the requested change in the body. The revision suffix is your naming convention; it is not a native version-history control. Keep the original r01 identifiable while the replacement is being reviewed.

Upload the new local file deliberately through the route from Chapter 1. Unless you have explicitly confirmed a supported replacement operation and its result, treat r02 as a separate stored item. Do not assume the new upload inherits the original’s link, star, direct grants, comments or location. Inspect each of those that your workflow needs.

Place r02 in the intended folder using the move procedure if necessary. Check the new item’s complete name, internal marker and substantive change through a permitted viewer. Read Share again: a familiar folder may supply inherited rights, but it does not establish that all direct grants from r01 transferred. Copy the actual r02 link and use it in the new review request. Keep any earlier link clearly associated with r01.

Rename changes the item’s label. It does not by itself prove that the body changed from r01 to r02. Renaming the old item to r02 while leaving r01 inside would make the review less reliable. Likewise, an Import or Save As label in a viewer is not sufficient evidence of a replacement chain. Use a native replacement or history feature only when you understand its observed controls and saved outcome for the actual file type; this course does not infer one from upload success.

Decide what happens to the older draft

Do not delete r01 simply because r02 exists. The old item may be referenced by an earlier review, an outstanding task or an audit requirement. Ask the responsible owner whether it should remain available, be clearly marked as superseded, or be handled under the organisation’s retention process. Deletion is a separate consequential action, not a routine final step in this practice.

When communicating the revision, say what changed and which item now needs attention. For example: “r02 clarifies what participants should prepare. Please use the new r02 link and confirm that the preparation section is clear.” Avoid calling it approved until the relevant reviewer actually supplies that decision. A file can be stored correctly, shared correctly and still need substantive changes.

Recover without creating more ambiguity

If two similarly named uploads appear, stop and compare complete names, contents, locations and available item links before choosing the working copy. Do not delete either until you know which references and review decisions belong to it. If a move appears uncertain, inspect both locations rather than uploading again. If a grant appears uncertain, reopen Share rather than repeatedly selecting the person. If a reviewer’s answer is vague, ask for the revision and requested decision rather than interpreting silence as approval.

Keep a short working note containing the current filename, internal revision marker, actual folder, agreed audience and latest review decision. This is a practical handoff aid, not a substitute for the saved application state. Recheck the affected part after a change: moves can affect inheritance, revised uploads can create new items, and renamed labels can drift from the body.

Practice: ask an agreed partner to review r01, then make one harmless content improvement in a separate r02 file. Upload, locate, inspect and share r02 through the authorised route. Ask for a revision-specific decision and explain the status of r01 without deleting it. Expected result: the recipient can identify the intended revision and return an actionable decision; you can distinguish stored, readable, accessible and approved instead of collapsing them into one “done”.