← All tools

Job Change

Track job changes across your Salesforce and HubSpot contacts

Ask which contacts have moved, and queue each departure for review.

SalesforceHubSpotReversible

People who have already left. A third of a contact database goes stale every year. The champion who bought last time is gone, the emails bounce into a black hole, and the account team finds out at renewal.

Job change is where this product started, and it is the one tool that runs in two directions.

Reactively, a departure arrives as a signal: a provider webhook, or a rep flipping a status field in the CRM. One trigger, one contact. The workflow reasons about what follows and queues it.

Retrospectively, a run asks the same question of a whole scope at once. That is the tool here: which of these contacts have moved, and what should happen about each one.

What follows a departure is more than one write. The contact is archived with a departure status, the account team is told, and the person is created at their new employer with the employer account created too if you do not already have it.

How a pass runs

From scope to record.

  1. Scope. A run names the contacts to ask about.
  2. Ask. Each contact in scope is checked against the provider for a change of employer.
  3. Reason. A departure is turned into the set of actions that follow from it, each one scored and explained.
  4. Review. Every action lands in the queue with its before state and its reasoning, for a person to approve or reject.
  5. Execute and record. Approved actions are written and stored with their prior values.

The detail

What it needs and what it does.

Object
Contacts. An account does not change jobs.
Configured in
Rules, under Backfill Heuristics, which the reactive path reads as well.
What it writes
A departure status on the contact, the new contact at the new employer, the employer account if it is missing, and a Slack notice to the owner.
Who releases it
A person, per action. Departures are queued for review rather than written on dispatch.
Reversible
Yes. Each action is stored with its prior state and can be put back.
CRMs
Salesforce and HubSpot.

Consequence

The departure is the signal. The work is what follows it.

Detecting that somebody left is the easy part and the least useful.

A tool that told you a contact had moved would leave you with a list and the same amount of work. The value is in the consequence: this person is gone, so this contact should be archived rather than emailed, this account team should hear about it, and this person is now a contact at a company that may not be in your CRM at all.

Every one of those is proposed with its reasoning attached and nothing is written until somebody approves it. A departure is exactly the kind of event where being confidently wrong is expensive.

For agents

The tools your agent calls.

Reads are free and need no permission to write. Anything that changes a record is a separate grant.

list_employer_changes who the provider says has moved read
create_job_change_run a run over a scope you name write
run_job_change_sweep ask the question across a scope now write
dispatch_run start it write
← All tools Create →

Where to start

Find out how many you have.

The readiness scan runs detection against your own CRM and reports what it finds, before anything is merged.

Run a readiness scan Request a demo