A user selects a Drive item called Monthly report and asks an agent to export it. The item is a shortcut. Another file with the same name also appears in the search results.

A fragile workflow takes the first matching filename and downloads it. A better workflow preserves what the user selected, resolves the shortcut's target and identifies the artifact it actually produced.

This guide is for developers building document preparation skills. The goal is an accurate export handoff, not broad access to someone's Drive.

Methodology and selection criteria

We reviewed Google's Drive shortcut guide, File resource reference and download/export guide on October 8, 2026. The monthly-report example and acceptance cases below are proposed designs. We did not access a user account or export a real document.

The selection criterion is the identity boundary between a navigational entry and content. This guide focuses on ordinary stored binary files and common Docs, Sheets and Slides exports. Specialized file types need their own documented handling.

Preserve the selected entry and resolved target

Google documents shortcuts as files pointing to other files or folders, with a shortcut MIME type and target information. Shortcut names can differ from target names. A shortcut can break when the target is deleted or access is lost. Drive shortcut guide.

For our fictional request, preserve the selected entry ID and name before resolving anything. If the entry is a shortcut, read its target reference and obtain that target's current metadata through the authorized account. Otherwise, the selected entry itself is the target.

Do not silently replace the original selection with a fresh filename search. If the target cannot be retrieved, report that boundary. Finding another Monthly report does not show that it is an acceptable substitute.

If the target is a folder, stop the file-export path. Listing or processing its contents is a different scope that the workflow must establish separately.

Do not use names or shortcut icons as identity

The File resource reference states that names are not necessarily unique within a folder. It also defines a shortcut's target MIME type as a snapshot captured when the shortcut was created. The target ID and the current target metadata serve different purposes. Drive File resource.

Our recommendation is to resolve by ID, then choose behavior from the actual target's current type and capabilities. A remembered icon or filename extension should not decide how the agent retrieves content.

A useful identity record has three layers:

Layer	Proposed record	Question it answers
User selection	Entry ID, displayed name and account context	What did the user point at?
Resolved source	Target ID and observed current metadata	What content object did the workflow resolve?
Output artifact	Saved output reference, format and completion evidence	What can the user now inspect?

Keep this record private to the workflow. It is not a reason to place file identifiers, account details or access credentials in public analytics.

Choose retrieval after resolution

Google distinguishes downloading stored binary content with files.get and alt=media from exporting Workspace documents with files.export into a supported format. Its guide also instructs callers to check capabilities.canDownload before download or export, and describes separate paths for specialized cases such as Google Vids. Drive download and export guide.

In our workflow, the requested output format should be explicit. “Export the report for reading” might lead to a PDF proposal; “prepare an editable spreadsheet” is a different deliverable. Ask when the distinction matters rather than silently optimizing for whichever operation is easiest.

If the requested format is unsupported, return a clear limitation or propose an alternative. Do not rename an incompatible file extension and call the conversion complete.

Likewise, a denied capability is not an instruction to switch accounts, loosen sharing permissions or look for an unrestricted copy. Those would change the authorization boundary.

Deduplicate work without erasing provenance

Suppose two selected shortcuts point to the same target. Our proposed batch policy is to avoid redundant retrieval when the target, requested format and processing context are equivalent, while preserving both selections in the handoff record.

Now consider two different target IDs with the same name. Keep them distinct until the user or an explicit task rule establishes otherwise. A name collision is not a duplicate-content decision.

Even one target can change over time. Record when metadata and output were obtained, and do not describe a file ID as an immutable content version. If exact-version export cannot be established for the chosen path, say so.

For the produced artifact, a locally calculated hash can identify the saved bytes for a later handoff. It is not proof that the document is accurate, authorized for publication or identical to every future export.

Check the artifact, not just the request

For the fictional report, the handoff should show the selected shortcut name alongside the resolved source name when they differ. It should also identify the output format and provide a durable artifact reference.

Before claiming completion, check that retrieval completed and the result can be opened by the intended consumer. Then inspect a task-relevant feature, such as the reporting period or expected worksheet. A valid PDF of the wrong report is still the wrong deliverable.

Separate preparation from distribution. Permission to export a document does not automatically authorize sending it to external recipients. Our file-and-recipient approval guide covers that later boundary.

Limitations and a proposed acceptance exercise

Use an authorized test folder with non-sensitive fixtures: a direct file, a shortcut, two namesakes, two shortcuts sharing a target, a folder target and an unavailable target. Add an unsupported output-format request.

Expected behavior should be written before running the workflow: preserve selection identity, resolve only the intended target, avoid arbitrary substitutes and return a precise stop reason when necessary. These cases are a proposed exercise, not reported test results.

Collaborative edits can still occur during retrieval. This workflow does not claim atomic snapshot semantics across metadata reads and exports, nor does it establish a universal version-pinning method for every Drive file type.

A reusable skill found through the skills directory can guide this process, but its instructions are not evidence that the connector implements it. Ask for the three-part handoff: selected entry, resolved source and actual output.