---
title: Using an app you connected
description: Connecting an app doesn't put it into a run. Here is how to hand a run access to one, how to keep a run to just the apps you meant, and when approval arrives.
---

Connecting an app and using an app are two separate steps, and this is the one people miss:
**a connected app is not automatically available to a run.** Built-in Add-ons are all on by
default; connected apps are not. You add them to the run.

If you haven't connected anything yet, start at
[Connecting your apps](/docs/connecting-apps) — that page covers linking accounts, how your
credentials are stored, and which actions stop for approval no matter what. This page is
what happens afterwards.

## Handing a run access to one

**Do it from inside a chat, not from the home screen.** That is the first practical thing to
know, and it is not obvious. The home composer does not read your connections at all: every
app in its list reads *Connect in Apps* whether you have connected it or not, and tapping one
takes you to the Apps screen rather than adding it to the run. So send your opening message
first, then set the apps up in the chat.

In the chat, open the panel above the composer — the button reading **What it can use**, which
carries a count of what is currently on. The panel is headed **This run — Just for what you're
about to send**. Under **Can use** the list is grouped *Research*, *Workspace* and *Create*,
and your apps sit in **Workspace**, each with a one-word state beside it. A connected one is
selectable; an unconnected one still sends you to Apps rather than pretending it selected
something.

Once added, a connected app appears as a chip above the input, so you can see that *Gmail*
is about to be in play. Built-in Add-ons deliberately don't chip — there are too many of
them and they're always on — but an app being there is always the result of a deliberate act
and is always shown.

Your selection persists in that chat. Reopen the chat tomorrow and the apps you gave it are
still the apps it has.

## Keeping a run to just the apps you meant

That same list is the answer to "can I limit this run to only these apps?" Yes — the panel
footer states the rule: *Only what you pick here is available to this run.* Whatever you
haven't picked isn't there for that run, including built-ins.

Two practical shapes:

- **One app, on purpose.** Turn off the built-ins you don't need and leave the one app on,
  when you want a run reading your Drive and nothing else.
- **Everything except.** Leave the defaults and add only the app the job needs. This is the
  common case and the one to reach for by default.

The consequence of narrowing is worth knowing: if the run turns out to need something you
didn't give it, **it stops and asks** rather than quietly reaching for it. An over-narrowed
run comes back with a question instead of a result. See [Add-ons](/docs/add-ons) for the same
mechanic applied to the built-ins.

## Do you have to name the app in your request?

No. You don't have to write *"using Gmail, find…"* — a run that has an app available will
use it when the job calls for it. But naming it is still the better habit for two reasons.
It removes the ambiguity about which of two places a file might be in, and it makes the
request self-documenting when you re-read the chat later. *"Find the Q3 deck in Drive and
summarise it"* is a better request than *"summarise the Q3 deck"* even though both work.

What naming an app does **not** do is grant access. If you name an app you haven't added to
the run, the run stops and asks — the request is not the permission.

## When approval arrives

Not up front. Approval arrives **at the moment it is about to act**, mid-run, describing the
specific thing it wants to do. That is deliberate: an approval up front would be a blanket
one, and this way you are approving an actual email rather than the idea of email.

The default is *Before anything leaves this app* — sending, publishing, buying or changing
things. In the same panel you can loosen that to *Before sending or publishing*, or to
*Don't check with me*. Underneath all three there is a floor: **sending or publishing always
stops for you**, even on *Don't check with me*. That one is not a preference.

While it waits, nothing runs and nothing is charged. It waits indefinitely — leaving an
approval overnight costs you nothing and loses you nothing.
[When it checks with you](/docs/when-it-checks-with-you) covers the controls in full.

## Where the record is

App work happens inside a run, so it lands in the same two places everything else does: the
run's own step list, and its receipt. Check what it says it did against the steps rather
than against its closing summary — see
[Reviewing what comes back](/docs/reviewing-what-comes-back).