When access is missing

A run that cannot reach a tool it needs does not improvise. It stops, and it says which tool. That is the whole behaviour, and it is worth stating plainly because the alternative is the failure mode that matters most: output that reads as though it had read your calendar when it had not.

Before you deploy

The setup checklist lists every tool the Playbook declares and marks the ones with no Connection. A Playbook cannot be deployed until they are all satisfied, so the problem is found while you are building rather than by a customer.

An expired or revoked connection appears there too, as one to reconnect rather than one to add. The wording is different because the fix is different.

Before a run does any work

The same check runs again at the start of a run, and it is the same rule rather than a second implementation of it. If a required tool has no live Connection, the run fails immediately, before any step executes, with the missing names in the reason.

Nothing partial happens. No step runs, so no work is charged for and no side effect occurs.

What the message tells you

Which tools, by name, and whose problem it is. A tool the operator was supposed to connect reads differently from one you were, because the two have different people to go and fix them.

Why not carry on without it

Because a run's output is supposed to be the work, and work built on a tool that was not there is not the work. The runtime would rather return a failure you can act on than a document that looks finished and is not. That rule holds everywhere: missing information produces an honest request or an honest failure, never invented data.