Skip to content
Tallyfy

Bulk operations

Launching many processes at once

Section titled “Launching many processes at once”

Launch two hundred processes with one command. You put one row per process in a spreadsheet, save it as a CSV file, and point the launch command at it. The Tallyfy CLI works through the list for you: it paces itself around rate limits, keeps going when a single row fails, and tells your script exactly how things went when it’s done.

The CSV file

Section titled “The CSV file”

Each row launches one process. The header row names the inputs: a name column sets the process name, and every other column is a kick-off form field. Name a field by its label (what you see on the form), by its alias, or by its field ID. A file for a customer onboarding blueprint might look like this:

name,Customer email,Priority
Onboard ACME Corp,contact@acme.example,High
Onboard Beta LLC,ops@beta.example,Normal

Values follow the field’s type. Text, date and email fields take the value as you’d write it. A dropdown or radio field takes the option’s text, like High. A multi-select takes several option texts separated by commas. The CLI turns each one into the shape the API expects, so you don’t have to.

If a header doesn’t match any kick-off field on that blueprint, the command stops before launching anything and prints the fields that do exist. That’s deliberate. Fixing a column name takes a second, while discovering next week that two hundred processes launched with one column quietly missing does not.

Run tallyfy process launch --help for the exact column reference for your version.

Preview first, launch second

Section titled “Preview first, launch second”

--dry-run prints the API calls the CLI would make for every row without executing any of them. Check the count and spot-check a few values, then run it for real:

Terminal window
tallyfy process launch --from-csv launches.csv --dry-run
tallyfy process launch --from-csv launches.csv

The dry run resolves every header against the blueprint and prints the exact request it would send for each row. It costs nothing and catches the classic mistakes: a stale file, a missing column, a header that doesn’t match a kick-off field, or a dropdown value that isn’t one of the options.

When some rows fail

Section titled “When some rows fail”

Big batches rarely fail all-or-nothing. If some rows launch and others don’t, the CLI finishes the batch and exits with code 9, the dedicated partial-failure signal. Your script can branch on it: alert a person, log the run, and avoid blindly re-running the whole file, which would duplicate the processes that did launch. The full exit-code table is in troubleshooting, and handling idempotency explains duplicate-safety patterns in more depth.

Rate limits are handled for you

Section titled “Rate limits are handled for you”

Tallyfy’s API throttles bursts, and a 200-row launch is exactly the kind of burst it throttles. The CLI paces itself automatically when the API asks it to slow down, so big batches simply take a little longer instead of crashing partway. If a limit truly can’t be worked around, the command exits with code 6 so your script knows to retry later. The limits themselves are described in the API documentation.

For developers

Section titled “For developers”

(Skip this unless you’re setting up the technical side.)

  • Every list verb exports machine-readable output for reconciliation, for example tallyfy process list -o csv > processes.csv after a big launch.
  • Use ndjson output when you’re streaming results into another tool one record at a time.
  • Unattended jobs should set the TALLYFY_API_TOKEN environment variable and pass --yes for any ask-level action, since the CLI never prompts without a terminal. See CI/CD approval gates for the headless rules.
  • --quiet trims the output down when you only care about the exit code.
Section titled “Related articles”

Cli > Command reference

Tallyfy CLI commands follow one resource-plus-verb pattern with aliases matching both UI and API…
Get in touch
About Tallyfy