Deploy

Deploy takes the artifacts that Work produced, zips them into a Salesforce metadata package, and submits the package to the Salesforce REST Metadata API. It is the first and only phase that writes to your org. Deploy always gives you the choice between Validate (a checkOnly deploy that runs every validation without committing) and Deploy (a real deploy that commits changes).

For production orgs, Deploy defaults to Validate. Salesforce's checkOnly mode runs the exact same validation path as a real deploy — dependency checks, syntax checks, test execution where applicable — without committing any metadata. If Validate passes, you know a real Deploy would pass too. If Validate fails, you see the error in chat with the offending file, and you can go back to Work to fix it. For sandboxes, Deploy goes straight to deploy because the cost of an error is tiny.

When a task mixes different metadata types — say a custom field, a permission set that grants it, and a flow that uses it — the order Salesforce processes them matters. Deploy surfaces this phasing before you click Deploy so you understand the dependency story.

1. Custom objects and fields — so referenced fields exist before anything reads them
2. Permission sets and profiles — so FLS can attach to the fields from phase 1
3. Apex classes and triggers — so they can reference both the fields and the permissions
4. Flows, deployed as Draft (never auto-activated in the same step)
5. Activation post-verify — you activate the new flow version manually in Salesforce Setup after confirming it's correct

The pipeline currently submits everything as one zip, so Salesforce handles the internal ordering for the first three phases. What Deploy protects you from is the flow-activation foot-gun: a freshly deployed flow that turns out to be wrong cannot be cleanly rolled back, so Deploy always ships flows as Draft.

When a deploy lands, you see a result message in chat: a green check on success with the Salesforce deploy ID (so you can look it up in Setup → Deployment Status) or a red cross on failure with the error text Salesforce returned. On success, Deploy offers the next environment ("deploy to production now?") or a mark-done button. On failure, Deploy offers Back to Work and Retry.

Each connected org stores its own highest supported Salesforce API version. OrgBolt probes this during OAuth and uses it in both the package.xml version tag and REST URLs. That means a task deployed against a fresh Winter '26 production org will use a newer API version than a task deployed against a legacy sandbox, and you never have to think about it. If you ever reconnect an org, the probe runs again.