302 - Exporting data

301 covered building dashboards and reports, which are views meant to live inside the portal. 302 is the case where the deliverable is a file meant to leave the portal. Both kinds of output land in the same Assets page; the producer tool differs.

Exports are different from dashboards in one operational way: the cost of getting them wrong is higher. A wrong dashboard prompt produces a wrong view that scrolls off and you try again. A wrong export prompt can produce a 100,000-row asset, with a sensitivity tag, that someone else now has to clean up. The cure is so simple it is easy to skip: sample the query first, with the agent in chat, and only then export the full set.

This is not a Plexara invention. The Trino Export tool description tells the agent to do exactly this, every time. Your job is to lean into the rhythm. Ask for ten rows, look at them, then ask for the full export. The next section is the diagram.

Three steps cover almost every export session. Sample, export, receive. Each step has its own purpose and its own cost. The sample is the cheap protection against the expensive mistake. The export is the moment the bytes commit to S3. The metadata response is what you read back to your teammate so they know what they are about to download.

Trino Export speaks four formats: CSV, JSON, Markdown, and plain text. The choice is mostly about who is on the receiving end. A finance colleague who will pivot the data wants CSV. An engineering team that will feed a pipeline wants JSON. A wiki page that needs an inline table wants Markdown. A debugging session that wants to eyeball log-shaped output wants text.

The agent picks the format from the word you use. "Spreadsheet" tends to route to CSV; "machine-readable" tends to route to JSON. Naming the format directly removes ambiguity. The table below shows side-by-side example prompts for each.

An export is not just data movement; it is data leaving the boundary your organization controls. Plexara bakes in three guards that you would otherwise have to remember on every export: read-only enforcement, CSV formula-character escaping, and sensitivity-tag inheritance. None of them require you to opt in. All of them apply on every Trino Export call. The point of naming them here is so you can answer your security team's questions later without going back to read source code.

A very common pattern after an export is "now make it shareable to a person outside the portal." An auditor, a vendor, a partner team without a Plexara account. Trino Export has a built-in shortcut for this: when your prompt indicates external sharing, the agent passes an option called create_public_link, which produces a public share URL alongside the asset in the same response.

Most of the time, idempotency is something the agent handles for you and you never think about. It matters most when exports run on a schedule or as part of a pipeline. The mechanism is simple: a short string the caller supplies that prevents the same export from being created twice if a retry happens. The callout below explains when it surfaces.

One conversation, in the shape you might actually have one. Sample first, export second, share once, sensitivity tag along for the ride.

Article 302 introduced create_public_link as a shortcut because it is so often paired with an export. Article 303 is the full story on sharing: named user shares with viewer or editor permission, public links with expiration dates and notice text, and the controls that let you revoke either kind when you no longer want the asset to be reachable.

Six terms cover the vocabulary of exports. The first three are what you will see in the agent's reply. The last three are the mechanics that protect you from common export mistakes.