Deploy: making it runnable

While you are writing it, what you have is a Draft Service: yours, named, and runnable by nobody. Not by a customer, not by a schedule, and not by you. Deploy is what changes that.

The setup checklist

The checklist audits the draft against its own contract and folds itself away when it is clear. It counts four kinds of thing.

• Connectors. Every tool the Playbook declares has to be connected, and any whose access has expired has to be reconnected.
• Reference files. Every declared reference has to resolve, and it has to be yours rather than the template's placeholder.
• Config inputs. Anything you set once as the owner has to actually be set.
• The Playbook itself. It needs at least one step, its steps have to name outputs that exist, and its trigger has to agree with its cadence.

Each item is fixable where it is listed. A missing connection carries the control that makes it; a placeholder reference opens for editing; a config value is given in the chat.

What Deploy does

It moves the Service from its draft stage to private. Nothing is created: the Service has existed since you started making it, and this is a transition rather than a birth. Nothing is published either. Private means your business can now create an Instance and make runs; nobody outside it can see anything.

The control is disabled until the checklist is clear, and it says so rather than failing silently when pressed.

What comes after

Run it. A private Service is a real one, and running your own work is the point of Deploy rather than a rehearsal for publishing.

It is also the gate to publishing: a Service can only be published after a successful run through one of its Instances, so a public listing is always backed by work that actually happened. See Publish.

There is no undeploy

A Service that has been deployed stays deployed. Returning it to its draft stage is not something the product does today, so the thing to be sure of before deploying is that the Playbook is one you want to keep.