Move work between the tools you already use

Outcome

Where the required tools are available and approved, ChatGPT Work can help with a task that spans applications. Identify the source for each claim and link the resulting document, spreadsheet, or presentation back to it.

Check source dates before reusing information and review the result in its destination app. Get approval before changing a shared source or publishing the result.

When to use it

Use this pattern whenever a deliverable crosses two or more applications. For example, a request arrives in an approved messaging tool, source material lives in documents and spreadsheets, a decision is scheduled in a calendar, the result is presented in slides, and a reusable workflow becomes an approved shared application.

It is especially valuable for recurring reviews, meeting preparation, reporting, operational intake, and tool building. For a simple one-off task in one document, keep the workflow simple.

Before connecting surfaces, identify which application is authoritative for each kind of fact. A chat message can route work, but it should not silently replace the maintained tracker or signed-off document.

Operating pattern

Start with a source map. For each application, define:

• Its role in the workflow.
• The artifact or field that is authoritative.
• The owner and expected freshness.
• What may be read automatically.
• What may be drafted locally.
• What requires explicit approval to change.
• How downstream artifacts point back to evidence.

Then follow a read–transform–review–act sequence. Re-read the live source immediately before using mutable facts. Transform material into a draft while preserving citations, units, dates, and uncertainty. Review the draft in the destination’s actual format. Act only when the required human approves the specific external mutation.

Prefer links and compact handoffs over pasting large copies between tools. When an artifact becomes recurring and interactive, consider promoting it to a Site or application, but keep its data contract and approval model explicit.

Copyable implementation

# Cross-application workflow map

Workflow: [name]
Decision owner: [role]

| Surface | Role | Canonical artifact | Freshness | Allowed action |
|---|---|---|---|---|
| Chat | Intake and discussion | [channel/thread] | [observed timestamp and currentness rule] | Read; draft reply |
| Calendar | Time and attendance | [event] | [observed timestamp and currentness rule] | Read; propose change |
| Docs | Narrative source | [document] | [rule] | Read; draft locally |
| Sheets | Structured source | [sheet/range] | [rule] | Read; analyze |
| Slides | Decision presentation | [deck] | [rule] | Draft; preview |
| Site/App | Reusable experience | [project] | Versioned | Build locally |

Mark unknown or stale coverage explicitly. These surface roles and action examples do not establish access or authorization.

Handoff contract:
- Source facts and timestamps:
- Transformation performed:
- Assumptions:
- Destination artifact and state:
- Required reviewer:
- External action awaiting approval:

Example

For example, an operations team prepares a monthly review. A chat thread contains the request, a calendar event establishes the deadline, a document holds qualitative updates, and a spreadsheet contains the maintained measures.

ChatGPT Work reads the event and live sources, reconciles dates and labels, and creates a local presentation draft. It places source references in speaker notes and marks one missing update as pending. After a human reviews the deck, the team decides that the repeated assembly work deserves a small internal Site. The Site reads a versioned, public-safe sample dataset during development; connecting live data remains a separate approved implementation step.

Approval boundary

Reading connected sources does not authorize changing them. Drafting a message does not authorize sending it. Building a local Site does not authorize deployment. Creating an application package does not authorize installation, access changes, or activation.

Require specific approval for outbound messages, calendar invitations or responses, edits to shared artifacts, permission changes, deployment, publication, and connections to live systems. Preserve the exact draft or version that was approved; a later revision needs another review if the change is material.

Validation

Validate both content and surface behavior:

• Re-read mutable sources immediately before finalizing the draft.
• Confirm owners, dates, units, and definitions across applications.
• Verify that links resolve for the intended audience.
• Preview Docs, Sheets, Slides, and Sites in their rendered form.
• Test empty, stale, missing, and conflicting source states.
• Confirm the destination clearly displays draft, reviewed, deployed, or published state.
• Check that copy, export, and handoff paths retain source attribution.

For applications, also test permissions, error states, keyboard use, responsive layout, and recovery after an interrupted run.

Failure modes

The most common failure is state collapse: a local draft is described as live, an installed package is described as active, or a successful build is described as deployed. Another is source laundering, where a copied value loses its date, owner, or definition as it moves through applications.

Watch for silent live edits, duplicated data stores, broken links, inaccessible artifacts, and “automation” that depends on a person manually repairing the output every run. Avoid connecting every tool merely because it is available. Each connection adds permissions, failure modes, and maintenance; it should earn its place in the workflow.