Using an app you connected

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 — 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 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 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.