Four steps, and one idea that makes the whole thing work: the chain runs per item, so step two always sees step one’s answer for the row it is actually on.
Paste what you want to run over — topics, URLs, SKUs, prompts, spreadsheet rows. One per line. Blank lines and duplicates are dropped.
Choose a ready-made batch, or point a step at anything in your install’s function catalogue. Use {{item}} wherever the row belongs.
See the literal calls for the first few rows before anything runs. This is where a wrong template gets caught.
Watch the progress, cancel if you need to, and take the table — or the CSV — when it finishes.
The thing you run is anything this install can call — a built-in tool, one of your own API routes, a saved action, an MCP tool, a connected vendor operation. There is no BulkForge-specific list of things it supports.
Read every page, then summarise each page. Step two sees step one’s answer for the same row — not for whichever row happened to finish last. That is harder than it sounds and it is why this exists.
It resolves your templates against the first few rows and shows the literal calls it would make. One wrong token costs a glance instead of five thousand failures.
A queued batch is a real job. Watch it, cancel it, restart the server — it picks up where it stopped instead of starting again.
A failed row is a row. The batch finishes and tells you which items failed and why, with a CSV you can hand to someone.
Save the URLs as a list, choose a batch that takes a URL — reading a page’s text, its metadata or its links — and queue it. You get one row per URL with the result beside it, and a CSV at the end.
Yes, and it is the point. Steps run in order per item, so step two reads step one’s output for the same row. Read every page, then summarise each page, in a single pass.
It stays a row. The batch carries on and finishes, and the table says which items failed and why. You can also set it to stop on the first failure if that is what you want.
A queued batch is a durable job. It checkpoints as it goes and resumes at the item it reached, rather than starting again.
Run now handles up to 200 items inline. Anything bigger should be queued, which is the lane built for it — watchable, cancellable, and safe across a restart.
Yes. Cancelling stops new items being dispatched and lets the ones in flight finish, so the partial table you keep is coherent rather than half-written.