You set up, hand off one sentence, and your agent runs the build loop — compose, lint, deploy,
and call the live onboard_new_hire endpoint to prove it works. You watch as
much as you want and step in at the checkpoints. Anyone can wrap one API as a tool;
composing a governed Salesforce + Slack orchestration into one agent-callable tool is
what only Workato makes possible.
brew / scoop install · wk version
▸
Start free — sign up for a Workato trial
(a Developer Sandbox you authenticate to with --region trial in step 1).
You'll also need a Slack account you can test in and a Salesforce demo account. Make a channel
called #team-welcome in Slack.
wk auth login --region trial
▸
In Workato: Workspace admin → API clients. Create a Client Role with
recipe / connection / lifecycle permissions, create an API Client with that role, and copy
the token (starts with wrk, shown only once).
Workato docs →
wk auth login bare fails before you can paste your token — --region must
be a flag. Use trial for the free sandbox; on a paid workspace use your data center
(us, eu, jp, au, sg, il, cn).
git clone …/recipe-skills.git
▸
wk init
▸
Scaffold the project before you prompt, so the agent writes the recipe straight into a folder
already mapped to your workspace — then deploying later is just wk push, no setup mid-flow.
“Build a Workato automation that…”
▸
Guided by the skills, your agent confirms your exact connection names and checks your Salesforce objects/fields exist. It asks — it doesn't auto-detect your workspace, so answer with your real connection names.
onboard_new_hire.recipe.json
▸
The agent writes onboard_new_hire.recipe.json — the multi-system flow in one file:
User record by email.#team-welcome, post the welcome message.wk lint onboard_new_hire.recipe.json
▸
Lint is a push gate — wk push refuses to deploy a recipe with
errors. It's deterministic validation the agent can't fake (datapill syntax, schemas, control-flow),
so the agent runs it and fixes until it's clean.
preview icon · Cmd+Shift+V
▸
Render the recipe as an interactive graph — click a node for its inputs/outputs and jump to the source line. Watch as much or as little as you want; an agent-confident run can skip straight to deploy.
wk push
▸
Deploying goes through Workato's packaging APIs, so the platform creates any missing Salesforce and Slack connections (and folders) as part of importing the recipe — nothing to pre-build in the UI. You authorize them in the next step.
recipe → Connections → sign in
▸
Authorize the connections the push just created: open the recipe in Workato, click the Connections tab, click each connection, and complete its sign-in in the right-hand panel.
That's your only hands-on bit here — once the connections are live, your agent takes over again to start the recipe and run the self-test.
wk recipes start · wk api … · curl
▸
With its connections authorized, your agent starts the recipe, wraps it as a live API endpoint, mints a key (printed once at creation, so it captures it), and calls the endpoint over HTTP — terminal-only, no human, no UI.
endpoint.json
A four-field file the agent writes — name, method (POST),
path (e.g. onboard), and flow_id (your recipe's ID).
Then the agent calls the live endpoint and reads the result:
The same collection can back an MCP server for chat-based agent clients:
wk mcp servers create --name "Onboarding" --folder-id <id> --collection <id>.
Reveal its token in the UI (AI Hub → MCP Servers → User access →
Developer MCP Token), then claude mcp add onboarding <mcp-url>.
The curl self-test already proved it works — MCP just makes it callable from chat clients.
open #team-welcome
▸
The success:true response is the machine's word for it — now see it for yourself. Open
Slack and go to #team-welcome: your demo new hire should be a member, with a welcome
message introducing them to the team. That's the Salesforce + Slack orchestration you built,
running on one real call.
Your agent called onboard_new_hire over HTTP, got success:true back, and
the new hire is in #team-welcome — a real governed call against the deployed endpoint, from
the terminal, no human. The tool it just built, now proving itself.
The loop is forgiving — when the agent wanders, one line of redirection puts it back. These are the snags worth a ready-made nudge:
Redirect: "Rebuild it with an API-endpoint trigger." A recipe-function or genie skill can't be self-tested over plain HTTP, and genie skills force identity-based MCP auth that the CLI can't hand you a token for.
MALFORMED_QUERY / "field not present"
Redirect: "Keep sobject_name, limit, and field_list out of the
action's extended_input_schema — list only the SObject's real fields." Those are reserved
config keys; in the schema they leak into the SOQL WHERE clause.
#team-welcome
Redirect: "Use invite_user_to_conversation (not …_to_channel), and resolve the
channel to an ID via conversations.list — there's no add-by-name."
nil / "no method 'where' for nil"
Redirect: "Native Slack adhoc output isn't body-wrapped — reference ["channels"], not
["body","channels"]." (Only the Workbot slack_bot adhoc uses a body wrapper.)
wk auth login 401s before you can paste the token
Redirect: "Pass --region as a flag (e.g. --region trial)" — it can't be
answered at a prompt, and a token from one region 401s against another.
You composed a governed, multi-system tool from one sentence. The same loop covers everything else — point your agent at another connector skill and go.