What is Motions

Most go-to-market teams have a routine they repeat every week: a list of accounts arrives, someone checks each company is the right record, looks up who works there, decides which accounts go to which rep, and updates the CRM. The steps themselves are usually scripted by now. What doesn’t scale is the work between them: remembering what ran, chasing the person who has to decide an unclear case, checking the result before anything is written, and keeping the rules the same from one week to the next.

Motions runs that routine for you. You describe it once, as code in a git repository, and Motions runs it over each new list of companies: it calls the data sources, asks people only the questions that need a person, and proposes CRM changes that someone approves before they’re written.

The pieces

A tenant is your company’s space in Motions, or your client’s if you run GTM for others. It has its own members, CRM connection, provider keys, motions and batches. Pruma creates tenants; see Tenants and members.

A motion is one routine, such as “weekly account preparation”. It’s a folder in the tenant’s repository with a motion.yaml that lists the steps, a TypeScript file for each step, and an optional rules.yaml for the values you tune week to week. Every push of a changed motion makes a new version, and one version is live: that’s the one new batches use.

A batch is one run of a motion over a list of companies, usually a list in your CRM. The batch keeps the version it opened with, so changing the motion halfway through the week doesn’t change a batch that’s already running.

A step is one piece of work. There are four kinds:

Brick	Kind	What it means
	Company step company	Runs your code once for each company. Most steps are this kind.
	Batch step batch	Runs your code once over every company that reached it, after none are still on their way. Use it to compare companies, such as finding duplicates.
	Checkpoint checkpoint	Runs no code. Holds every company until a time, an event, or someone releases it.
	Changeset changeset	Runs no code. Seals the CRM changes proposed so far into one package for an approver.

Company steps and batch steps run your code. They return facts about each company, which later steps read, or they move the company out of the batch with a reason, such as “no domain” or “outside the ICP”.

A source is a data provider that steps call through Motions, such as the RDAP domain registry, the Brazilian company registry, Exa search, an LLM, or an API you add yourself. Motions caches the answers, records what each call cost, and stops a step that goes over its spending cap. See Sources.

A question is how a step asks a person. It’s always closed: two to four options, a recommended answer, and the evidence behind it. Each kind of question has an owner, a deadline and a default, so an unanswered question never stalls the batch. See Questions.

A changeset holds the CRM changes the steps proposed, for every company that got that far. When nothing upstream is still running or waiting, Motions seals it. An approver sees each record’s value before and after, then approves it, and only then is it written. See Changesets.

Each company in a batch is in one lane, which tells you at a glance whether it needs anyone:

Brick	State	What it means
	Done done	Through every step.
	Moving active	Steps are running or queued for it.
	Waiting waiting	A step asked a question; the company waits for the answer.
	Parked parked	It stopped and needs someone: a step failed, hit a spending cap or ran out of provider credit. A company whose step is waiting on a timer shows here too, until the step runs again.
	Held held	Kept out of this batch on purpose: a step or an answer held it, or its changeset was rejected.
	Dropped dropped	Removed from the batch, with a reason such as no domain or outside the ICP.

A week with Motions

Here’s how a weekly routine runs once it’s set up. The names are made up; the mechanics are what the platform does.

1. Monday morning. The sales manager puts this week’s 200 accounts in a HubSpot list. You open a batch of the weekly motion on that list, from the app or the command line.
2. The steps run. Each company goes through identity checks, an ICP gate, signals and people search. Most go straight through. A few ask: “this domain is registered to a different company: same one or not?” goes to your queue; “there’s an open deal on another record: hold it or send it to the rep?” goes to the manager’s queue, due Monday at 18:00, and takes the recommended answer if nobody replies.
3. The changeset. Companies that reach the “write contacts” step wait there. When none are still moving or waiting before it, Motions seals the changeset. You review the new contacts and approve, and Motions writes them.
4. Friday. You change a threshold in rules.yaml and push. Next week’s batch uses the new version. This week’s batch keeps the old one unless you upgrade it.

Where things happen

In the app you open batches, watch them, answer questions and approve changesets. Its pages are Today (what needs you), Batches, Motions (versions and their code), Questions, Sources (what providers cost) and Settings.

In the repository you define motions. You test them on your laptop, then publish with the motions command line tool or from GitHub when a pull request merges. Small edits to a step or to rules.yaml can also be made in the app and sent back to the repository as a pull request.

What Motions doesn't do yet

Motions reads HubSpot but doesn’t write to it yet: an approved changeset is recorded, not sent. It doesn’t import spreadsheets, send e-mail, or let you create a tenant yourself. Limitations has the full list.