If you’re reading this, you probably have two problems: you use Salesforce, and you want better data in it—without endless manual entry or duct-taped solutions. You’ve heard Getsignals can pipe in useful intent data, but you don’t want to waste time on another “seamless” integration that quietly eats your Saturday. This guide is for you: sales ops, admins, or any tech-savvy person who just wants Salesforce to work smarter.
Let’s walk through, step by step, how to connect Getsignals to Salesforce. You’ll get the real caveats, what to skip, and how to make sure your data actually ends up where it’s useful—not buried in a custom object no one ever looks at.
What You Need Before You Start
Don’t skip this. Here’s what you’ll need:
- Salesforce admin access: You won’t get far without it. If you’re not an admin, get one on board now.
- Getsignals account: Confirm you have the right subscription tier—integrations usually aren’t part of the free plan.
- API access in Salesforce: If you’re on Salesforce Essentials or a super-limited plan, check if API access is enabled. No API, no integration.
- A test Salesforce record: Don’t test on your best lead. Have a throwaway lead or account for testing.
Pro tip: Block off an hour where you won’t be interrupted. Most of the pain comes from switching context or waiting for permissions.
Step 1: Find Your Integration Setup in Getsignals
First, log in to your Getsignals dashboard.
- Go to the “Integrations” or “Connections” panel. (If they’ve moved the menu since this was written, use their search or help docs.)
- Look for “Salesforce.” If it’s grayed out or says “Upgrade required,” you’ll need to talk to your Getsignals rep.
- Click “Connect.” You’ll probably see a Salesforce OAuth login prompt; sign in with your Salesforce admin account.
What to watch for:
If your org uses SSO or MFA, be ready for a couple of extra authentication steps. Don’t try to shortcut these—Salesforce loves to throw generic “insufficient access” errors.
Step 2: Authorize and Map Fields
This is where most integrations get messy. Getsignals wants to push data into Salesforce objects—usually Leads, Contacts, or Accounts.
- Authorize Getsignals: You’ll be asked to grant Getsignals access to your Salesforce instance. This is standard; just read the permissions so you know what it’s touching.
- Choose your objects: Decide whether you want Getsignals data on Leads, Contacts, Accounts, or all three. (If you’re not sure, start with Leads.)
- Map fields: Getsignals will show you a list of its data points (like company, intent score, last seen date). You have to match these to Salesforce fields. If you don’t have matching fields, you’ll need to create them in Salesforce first.
Skip this? Don’t.
Lazy mapping means your sales team will ignore the new data, or worse, you’ll overwrite something important.
Quick field mapping checklist: - Don’t map everything. Only grab what you’ll actually use. - Use existing fields where possible. Don’t create “Getsignals Intent Score” and then forget to add it to the page layout. - Document your mappings. You will forget them.
Step 3: Set Up Data Sync Rules
Most platforms will let you choose how and when data syncs. Getsignals is no exception.
- One-way or two-way? Almost always, you want one-way: Getsignals → Salesforce. Two-way sync sounds cool, but can quickly create duplicate or conflicting data.
- Real-time vs. batch: If you have a small Salesforce org, real-time is fine. For bigger teams, batch updates (every hour or daily) are safer and less likely to trigger Salesforce governor limits.
- Deduplication: Decide how Getsignals should handle records that already exist in Salesforce. You usually want to match on email or domain.
What to ignore:
Don’t get sucked into advanced “custom triggers” unless you have a specific use case. Start simple. Complexity breeds bugs.
Step 4: Test the Integration (Seriously, Test It)
This is where most folks get burned. Never trust that “Connected!” green checkmark.
- Push test data: Use your test lead/account. Trigger a Getsignals event, or manually push data if the option exists.
- Check Salesforce: Did the data show up? Is it in the right place? Was anything overwritten?
- Check field visibility: If you mapped to custom fields, make sure they’re visible on the relevant page layouts. Salespeople won’t use what they can’t see.
- Test deduplication: Try pushing the same record twice. Make sure it updates, not creates a duplicate.
If something’s broken:
Check field-level security in Salesforce first. Nine times out of ten, the data is there—you just can’t see it. Next, check Getsignals logs (if available).
Step 5: Roll Out to Your Team
Now for the human side. What’s the point of new data if no one uses it?
- Update layouts: Put the new Getsignals fields somewhere visible, but not overwhelming.
- Tell your team: A quick Loom video or screenshot goes further than a Slack message. Show them what’s new and why it matters.
- Collect feedback: Salespeople will tell you if the data is useless or confusing—if you ask.
Pro tip:
Don’t promise more than the integration delivers. Intent data is helpful, not magic. Set the right expectations.
What Works, What Doesn’t, and What to Ignore
What works well
- Intent signals in context: Seeing “high intent” right next to a lead is actually useful—if your team knows what it means.
- Automated updates: No more chasing down SDRs to fill in fields.
What doesn’t
- Over-mapping: Too many new fields just get ignored.
- Complex automations out of the gate: Start simple. You can always layer on more later.
- Assuming integration = adoption: You still need buy-in from the team.
What to ignore
- “AI-powered enrichment” unless you know exactly what data’s being added. More isn’t always better.
- Advanced filter rules for your first go. Get the basics working before building logic trees.
Next Steps and Keep It Simple
You’ve now got Getsignals and Salesforce talking to each other. Don’t overthink it. Monitor the integration for a week or two. If people aren’t using the new data, ask why. Iterate—add or remove fields as needed.
Remember, the goal isn’t to have more data. It’s to have useful data, in the right place, at the right time. Start small, fix what’s broken, and build from there. That’s how you get “seamless” data flow—not by believing every product demo, but by making your stack work for you.