Workflows as code means treating the definition of a business process like a software artifact. The blueprint gets exported to a plain text file. The file gets committed to git, reviewed in a pull request, and promoted from a sandbox organization to a production one with a single command. No screen-share, no rebuilding the template by hand in the other account.

This week we shipped v0.1.0 of the Tallyfy CLI, a command-line client for macOS, Windows, and Linux that makes all of that real. It’s brand new, so you won’t find adoption charts or glowing usage numbers here. What we can show you is the four jobs it does well on day one, the guardrails wrapped around them, and the things it deliberately won’t do.

What workflows as code borrows from infrastructure as code

Ops teams solved a version of this problem a decade ago. When Martin Fowler published his overview of infrastructure as code in March 2016, the core idea was defining servers and networks through source code that could be treated like any software system. The practices he credits to Kief Morris read like a to-do list for process management: keep definitions in files, version all the things, prefer small changes over big batches, and lean on the version history when the audit lands.

Swap “server” for “workflow” and the list still holds.

A workflow blueprint is a definition too. It says who does what, in which order, with which form fields and deadlines. Yet in most companies that definition lives inside a web UI where the only record of change is somebody’s memory. Someone edits step six, nobody notices until the next launch goes sideways, and reconstructing what changed eats a morning. Git solved this for software years ago. DORA’s research on version control ties broad version control use directly to continuous delivery, and their current guidance says to version AI artifacts too, prompts and agent configuration files included, not application code alone.

That last part matters more than it looks. Hand an AI agent an unreviewed process and it executes the flaws right along with the steps, so the definition deserves the same pull-request scrutiny code gets. Versioned blueprints give your people, and increasingly your agents, something specific to follow. The same thread runs through most of our recent workflow automation writing.

Quick step back before the commands, because one sentence of vocabulary saves confusion later. Tallyfy’s UI says “blueprint” for a workflow template and “process” for a running instance of one, while the API says “checklist” and “run” for the same two things. The CLI leads with the UI words and quietly accepts the API words as aliases, so tallyfy checklist export and tallyfy blueprint export do the same job.

For the record, here’s the shape of the tool. The Tallyfy CLI is a command-line client for the Tallyfy workflow platform, written in Go and published at github.com/tallyfy/cli. Version 0.1.0 ships 23 top-level commands covering blueprints, processes, tasks, members, guests, groups, folders, tags, and organizations, plus auth, layered configuration, diagnostics, and shell completion for bash, zsh, fish, and PowerShell. Commands call the standard Tallyfy API at api.tallyfy.com and print results as a table, JSON, CSV, or newline-delimited JSON. Credentials resolve from a flag, the TALLYFY_API_TOKEN environment variable, a configurable helper script, or a token saved in the OS keychain, in that order. A raw tallyfy api command reaches any endpoint with the standard headers and retry policy applied. Releases ship with checksums, and tallyfy update verifies a downloaded binary against them before replacing the running executable.

Dry list, we know. The interesting part is what those commands chain into.

Blueprints in git, reviewed like code

A question that keeps coming up in support conversations: how do we move a blueprint from our sandbox organization into production without rebuilding it click by click?

Until now the answer was messy.

The honest origin story is less tidy. For years our internal answer was a folder of hand-rolled Python scripts calling the raw API to export and import templates. They worked, mostly. They were also a kludge: undocumented flags, one person who understood them, and a habit of breaking whenever the API grew a field. If you’ve ever cobbled together glue scripts against a vendor API, you know that lifecycle. The CLI started life as the replacement for our own duct tape. Call it dogfooding by necessity.

The flow now takes four steps. Run tallyfy blueprint export and you get the blueprint as JSON that’s built to be committed. Push it to a branch and open a pull request, where a colleague reviews the diff like any other change: a new approval step shows up as added lines, a moved deadline as one edited value. Merge it. Then run tallyfy blueprint import with the --org flag pointed at the target organization, and the reviewed version lands in production.

That review step is the whole point. A proper pull request gives a workflow change a reviewer, a timestamp, a discussion thread, and a revert button. Compare that with editing a live template in a UI at 5 pm on a Friday. Which version of events would you rather explain to an auditor in January?

One snag to know about. Export and import move the definition, and the definition is what git can review. Members and groups are their own objects with their own commands (tallyfy user, tallyfy group), because a blueprint export is the template, not the org around it.

Launch a batch of new hires from one CSV

Say fourteen people start on Monday. Employee onboarding is the classic bulk case: the same blueprint, fourteen kickoff variations, and an HR coordinator who would otherwise click through the launch screen fourteen times before lunch.

The CLI treats the spreadsheet as the source. Put one row per new hire in a CSV, then preview the batch:

tallyfy process launch --from-csv new-hires.csv --dry-run

--dry-run prints the API calls the command would make and executes none of them. Read that plan the way you’d read a Terraform plan: fourteen launches against the right blueprint with the right fields. A malformed row surfaces now, not halfway through the real run. Drop the flag to launch for real, and add --yes in scripts, because the CLI refuses to assume consent for writes when nobody’s at the keyboard.

Then there’s the exit code, which is the unglamorous hero of the feature. Errors map to specific codes: 5 when something isn’t found, 7 when validation fails. Exit code 9 means partial failure, as in some rows launched and some didn’t. Your wrapper script can catch a 9, stop, and page a person with the output instead of reporting green. We’d guess most bulk-launch horror stories come from tools that treated 12 successes and 2 silent failures as done. A batch that half-worked is a state your automation needs to hear about, and the CLI says it out loud.

Add --json when you want the results as structured output for your logs.

Fourteen new processes, one command, and a paper trail.

Can a deploy pipeline wait for a human?

This is the most engineering-flavored of the four jobs. CI/CD systems are brilliant at machines approving machines. They’re janky the moment a human needs to sign off, which is why teams bolt on chat approvals, shared inboxes, or a “reply YES to proceed” email hack. None of it leaves a record anyone can point to later.

tallyfy task wait is the building block. It blocks until a named task inside a process completes:

tallyfy task wait --process <process-id> --task "Approve production deploy" --timeout <duration>

Put that line in a GitHub Actions job, a Jenkins stage, or a GitLab CI step, between build and deploy. The pipeline pauses. The release manager sees the approval task in Tallyfy with its full context and approves it there, the same way any approval process workflow runs, and the command returns so the pipeline rolls on. Nobody pings Slack. The sign-off sits in the process history with a name and a timestamp attached, where compliance can find it in six months.

The --timeout flag does quiet load-bearing work here. Nobody wants a pipeline that hangs for a week because an approver went on holiday, so you set a ceiling and let the job fail loudly when it’s reached. Fail, page, escalate: your pipeline picks the policy. For credentials, follow the twelve-factor config rule and inject TALLYFY_API_TOKEN from your CI secret store. The twelve-factor argument for environment variables is exactly that credentials never end up committed next to the pipeline file.

Couldn’t you script tallyfy task complete and auto-approve your own gate? Sure. You’d be forging your own sign-off, and the process history would say so. Don’t.

Schedule nightly snapshots with cron

The fourth job is the least flashy and might age the best. Put tallyfy blueprint export in a nightly cron job, commit the output to a repo, and you get a dated history of every template your company runs on. tallyfy process export does the same for a live process when you want a point-in-time record of one run. Six months later, git log answers questions nobody thought to write down: when step six got a new owner, which week the deadline moved, what the process looked like before the reorg.

Cron jobs and prompts don’t mix, and the CLI knows it. When it detects it isn’t attached to a terminal it switches to --no-input behavior on its own, so it never sits waiting for an answer at 2 a.m. It fails with a real exit code your cron wrapper can log. Small design choice. Big difference the first time something breaks at night.

Worth being precise about what this isn’t, though. The CNCF’s GitOps Working Group defines GitOps principles as desired state that’s declarative, versioned and immutable, pulled automatically, and continuously reconciled. A nightly export gives you the versioned history and nothing else. No agent reconciles your org back to what git says, and if someone edits a blueprint in the UI, git finds out at the next export rather than instantly. It’s a one-way snapshot on purpose. Drift detection between the UI and the repo is a wishlist item, and wishing is all v0.1.0 does about it.

A correction before someone emails us: “workflows as code” oversells the typing involved. You won’t write code. The export is JSON the platform generates, and the what is a workflow basics don’t change because a file now exists. The “as code” part was always the discipline around the file, version it, review it, promote it, rather than the file format itself.

Guardrails first, and what the CLI won’t do

After sitting with v0.1.0 for a bit, our take is that the guardrails matter more than any single feature.

A CLI that can write to your production org needs a suspicious streak, and this one was built with it. --dry-run works on any command and shows the API calls without executing them, so every risky operation has a rehearsal mode. Destructive and write actions in scripts require an explicit --yes, and a non-interactive session never prompts, it fails, which means an unattended job can’t stall on a hidden question. Permission rules decide what the CLI may do at all: they merge across six settings scopes from personal defaults up to managed org policy, a deny always beats an allow, and a blocked command exits with code 4 so automation can tell refused from broken. Tokens get validated against the API at login and stored in the OS keychain, with an AES-256-GCM encrypted file as the fallback where no keychain exists, and verbose request logging redacts them. Project-level hooks only run in workspaces you’ve marked trusted with tallyfy trust, so cloning a repo full of someone else’s config can’t execute commands on your machine. And tallyfy doctor checks all of the above read-only, from credentials to connectivity to permission-rule validity, before you wire anything into a pipeline.

We wrote up the design story behind that config and permission system in how Claude Code shaped our CLI, if you want the architecture rather than the tour.

Fair enough, but what about the gaps? A v0.1.0 has them, and pretending otherwise would be silly. Here’s what it deliberately does not do:

• It isn’t a workflow engine. The CLI is a client of api.tallyfy.com, your processes run in Tallyfy’s cloud, and closing your laptop mid-afternoon strands nothing.
• There’s no built-in scheduler. Recurring exports and launches belong to cron, your CI system, or whatever already runs your scheduled jobs.
• Semantic blueprint diffs aren’t in it. git diff on exported JSON is the diff, and it’s a good one.
• Your token is the ceiling. The CLI talks to the same API with the same role you already hold, so it’s no side door around permissions.
• It won’t approve anything for you. task wait waits. The decision belongs to a person.

That list will shrink as versions climb, and parts of it, like the engine point, should never change. If you hit sharp edges, and at v0.1.0 you’ll hit a few, issues on the GitHub repo get read by the people who wrote the code.

Install is one line on a Mac, with Windows and Linux builds published alongside each checksummed release:

brew install tallyfy/tap/tallyfy
tallyfy login
tallyfy doctor

tallyfy login opens your Tallyfy settings, takes a pasted token, checks it against the API, and stores it safely. tallyfy doctor then confirms the setup is healthy before you trust it with anything real. The full command reference lives in the CLI documentation.

Your workflows already run the company. As of this week, they can have a commit history too.