Playbook scope and Runtime scope

A required tool has to be satisfied by somebody's authorised access, and there are two answers to whose. That is what a Connector's scope says.

Playbook scope

The method uses the operator's own tools. The person who wrote the Playbook authorised the access, and every run uses it, the same way for everybody.

This is the normal case and the one the whole product is built around. A Playbook that reads your own calendar to produce your own digest is Playbook scope.

Runtime scope

The method reaches into the customer's systems instead. The access is bound to their Instance, so a Service that files things into a CRM files them into theirs, and each customer's authorisation is their own.

This is what makes a published Service able to work on somebody else's data without the operator ever holding their credentials.

What is built, and what is not

Playbook scope is complete. Declaring it, connecting for it, checking it before Deploy and resolving it at run time all work.

Runtime scope has no authoring surface. The declaration is honoured, a run resolves it against the Instance, and a Playbook that needs it says so in its own document. What there is no control for is adding one to a Playbook you are writing in the builder. If you need it, that is a change to the document itself.

A run that needs a customer-scoped tool and does not have it stops the same way any missing access does, and says which one it was. It does not fall back to the operator's access, which would be a customer's work quietly reading somebody else's data.