Setup Guide 1 of 3 Testsigma
Workflow Setup Guide

Two job change workflows,
built for your use case

Based on our conversation, Testsigma needs two distinct workflows - one for contacts who change titles within the same company, and one for contacts who move to a new company entirely. Each has different logic and a different outcome in Salesforce.

The two workflows at a glance
Workflow A
Title change - same company
Contact stays at same org but changes role or title. Update the existing Salesforce record - no new contact created.
Update existing record Title field push to SFDC
Workflow B
Company move
Contact leaves for a new employer. Mark old contact "no longer with company," then branch on whether the new account exists.
Mark departed Branch: existing vs new account
Before you start - prerequisites
Done Salesforce integration connected to Apollo
To do Create custom SFDC field: Contact.No_Longer_With_Company__c (Checkbox)
To do Create custom SFDC field: Contact.Previous_Email__c (Email) - for email trail
To do Mirror both custom fields in Apollo (Settings → CRM → Field Mapping) so workflows can write to them
Workflow A - Same Company

Title change,
same organization

When a contact changes roles internally - promotion, department move, reorg - Apollo detects the title change and updates the existing Salesforce contact record. No new contact is created.

Setup steps - Apollo Workflows
1
Navigate to Workflows
In Apollo, go to Engage → Workflows → New Workflow. Name it something like "Title Change - Same Company."
2
Set the trigger
Trigger: Job Change Detected. Then add a filter condition:
Trigger: Job change detected
Filter: Job change type = "Title change (same company)"
// This separates title-only changes from full company moves
3
Add the "Update contact" action
Add step: Update Contact. Map the following fields to auto-populate from Apollo's enriched data:
Title → {{ contact.enriched_title }}
Seniority → {{ contact.seniority_level }}
Department → {{ contact.department }}
4
Push to Salesforce
Add step: Push to Salesforce. Select Update existing contact (do not create new). Fields to sync:
Contact.Title → updated title
Contact.Apollo_Last_Enriched__c → today's date
✓
Enable & test
Toggle the workflow to Active. Run a test contact through manually to confirm the SFDC field updates correctly before opening it to your full database.
Tip
Enable Waterfall enrichment on this workflow so Apollo pulls from multiple data sources before writing - improves accuracy, especially for title fields.
Workflow B - Company Move

Contact moved
to a new company

When a contact leaves for a different employer, the workflow marks their old record as departed in Salesforce, then branches based on whether their new company already exists in your CRM.

Setup steps - Apollo Workflows
1
Create the workflow
Go to Engage → Workflows → New Workflow. Name it "Company Move - Job Change." Set trigger:
Trigger: Job change detected
Filter: Job change type = "New company"
2
Mark old contact as departed
First action: Update Contact on the original contact record. This is the "no longer with company" step:
Contact.No_Longer_With_Company__c → true (checkbox)
Contact.Previous_Email__c → {{ contact.current_email }} // save before overwrite
Contact status → "Job Changed"
Important
Copy the current email to Previous_Email__c before updating the record - this preserves your audit trail for downstream SFDC or Workbench review.
3
Add branching logic
Add a Branch step. The condition determines what happens at the new company - see the next tab for full branching logic.
Branch A - Account exists
New company already in Salesforce → create new contact record under that existing account. Assign to existing owner.
Branch B - Net new account
New company not in Salesforce → send alert to Bhavani / rep for review. Do not auto-create. Manual decision.
4
Pause any active sequences
Before or after the branch, add: Remove from Sequence on the original contact. Prevents bounced emails going to a company they've left.
✓
Enable workflow
Set to Active. Check enrichment activity log after first runs to confirm old/new email fields are populating correctly.
Workflow B - Detail

Branching logic -
existing vs. new account

This is the core of the company-move workflow. Apollo checks whether the contact's new employer already exists in your Salesforce - and routes differently based on the answer.

Branch condition setup
Condition to configure in Apollo
Branch condition:
New company domain exists in Salesforce accounts

// Apollo checks Account.Website / Account.Domain against
// the enriched new_company_domain from the job change record
Branch A - Account already exists in SFDC
A
Create new contact under existing account
Action: Create Contact in Salesforce. Link to the matched account. Populate with Apollo-enriched fields (new title, new email, phone).
A
Assign to existing account owner
Set Contact Owner to match the Account Owner in Salesforce. Keeps the relationship clean - the rep who owns that account sees the new contact automatically.
Branch B - Net new account (not in SFDC)
B
Do NOT auto-create account or contact
This was a deliberate decision from today's call - you don't want unknown accounts auto-appearing in Salesforce. Leave creation as manual.
B
Send an alert for human review
Action: Send Email Alert or Slack Notification to Bhavani (or whoever owns the review queue). Include the contact name, old company, new company, and new title.
Optional: add a relevance filter first
Before even reaching this branch, add a filter upstream: e.g., new company headcount > 50, or new company is in your target industry. This prevents alerts for irrelevant moves (e.g., contact moved to a 3-person startup).
B
Tag contact in Apollo for manual follow-up
Action: Add to List → "New Company - Pending Review." Creates a queue in Apollo that Bhavani can work through on a recurring cadence.
Audit Trail

Preserving the
old email address

A key ask from today's call: when a contact moves companies and gets a new email, you still need visibility into what their old address was - for Salesforce review, Workbench imports, or DataBler. Here's how Apollo handles that.

Where to see email change history
Enrichment activity log - Apollo
1
Go to the contact record in Apollo
Open any contact that has been enriched via a job change workflow. Scroll to the Enrichment History section on the right panel.
2
View field-level change log
Apollo logs every field change made during automated enrichment - including what the old value was and what it was replaced with. Email, title, company, phone are all tracked here.
3
Bulk view: Enrichment Job Activity
For batch review, go to Settings → Enrichment → Activity Log. Filter by workflow name or date range to see all changes made across your database.
Pushing old email to Salesforce (recommended)
Workflow step: preserve email trail in SFDC

Rather than relying on Apollo's internal log, the cleanest approach for your team is to copy the old email into a custom Salesforce field before the update runs. This makes it directly queryable via Workbench, DataBler, or SFDC reports.

// Add this step BEFORE the "update email" action in your workflow:

Action: Update Contact
Field: Contact.Previous_Email__c
Value: {{ contact.email }} // current email, before overwrite

// Then proceed with the enrichment update:
Field: Contact.Email
Value: {{ contact.enriched_email }} // new email from Apollo
What this gives you
✓ Old email preserved in Previous_Email__c - queryable in any SFDC report or Workbench export
✓ New email lives in standard Contact.Email - immediately usable by reps
✓ Full audit trail without needing to check Apollo's enrichment log separately
Salesforce Configuration

Salesforce fields
to create before you start

Apollo can only push data to fields that exist in both systems. You'll need to create two custom fields in Salesforce first, then mirror them in Apollo's CRM settings.

Custom fields to create in Salesforce (Object: Contact)
Create these in SFDC Setup → Object Manager → Contact → Fields
Required No_Longer_With_Company__c
Type: Checkbox (Boolean)
Label: No Longer With Company
Purpose: Checked automatically when job change workflow detects a company move. Lets reps filter for departed contacts in SFDC list views.
Required Previous_Email__c
Type: Email
Label: Previous Email Address
Purpose: Stores the contact's email before Apollo updates it. Enables before/after comparison in Workbench, DataBler, or custom SFDC reports.
Mirror in Apollo - CRM Settings
Apollo: Settings → CRM → Salesforce → Field Mapping
Apollo: job_change_flag
→
Contact.No_Longer_With_Company__c
Create mapping
Apollo: previous_email
→
Contact.Previous_Email__c
Create mapping
Apollo: title
→
Contact.Title
Already live
Apollo: email
→
Contact.Email
Already live
Controlling which contacts sync to SFDC

Per the call: Apollo is not currently pushing all contacts to Salesforce. The decision was to enable SFDC sync selectively - only for contacts that go through the job change workflow. This keeps your SFDC clean.

// In Apollo Settings → CRM → Sync Rules:
Push contacts to SFDC when: workflow tag = "job-change-processed"
// This ensures only job-change-enriched contacts are pushed,
// not your entire Apollo database