A SurveyMonkey Salesforce integration sends surveys from Salesforce records and writes every response back to the Contact, Lead, Case, Opportunity or custom record it belongs to, through SurveyMonkey's own SurveyMonkey for Salesforce app. Twopir Consulting designs the data model, the mappings, the Flow-triggered sends and the integration user, then supports it after go-live. Salesforce architects who treat survey data as CRM data.
Trusted by 500+ organizations — growing, mid-market and enterprise teams that run customer, patient and member processes in Salesforce with Twopir Consulting.
What We Configure
Authorising SurveyMonkey against Salesforce takes minutes. The problems show up later, when a CRM manager asks why half the responses sit on no record, or why last quarter's answers never arrived. These are the six we are most often asked to untangle.
Matching on an email address typed into the survey fails the moment Salesforce holds two records with that email. SurveyMonkey's own recommendation is to match on the Salesforce Record ID passed in a custom variable instead.
Mappings are saved to the Salesforce user who connected them. When that admin is deactivated, the mappings stop working, which is why SurveyMonkey recommends a dedicated integration user from day one.
By default only responses collected after a mapping is created sync. Older responses need a historical sync requested through SurveyMonkey's customer success team, one survey, collector and mapping action at a time.
The managed package writes one child record for every answered question. On a long survey with steady volume, that is a data-storage and reporting decision, not a detail to discover in the storage report.
Refreshing a Salesforce sandbox breaks its SurveyMonkey connection. Without a runbook for reconnecting and copying the mappings across, testing quietly stops working after the next refresh.
A read-only field, a missing permission or an unmatched record sends the sync to SurveyMonkey's error log, not to anyone's inbox. Unless someone owns that log, failed responses accumulate out of sight.
A SurveyMonkey Salesforce integration connects SurveyMonkey surveys to Salesforce records in both directions: Salesforce decides who is surveyed and when, and each response is written back to the record it belongs to. It runs on SurveyMonkey for Salesforce, SurveyMonkey's own app, which connects to your org over OAuth 2.0, maps responses either into its managed-package objects or into fields on any standard or custom object, and sends surveys when a Salesforce Flow fires.
Three parties own three different things. SurveyMonkey owns the surveys, the collectors and the connector; SurveyMonkey for Salesforce is an Enterprise add-on that you obtain through SurveyMonkey Sales or your Customer Success Manager. Salesforce owns the records, the automation and the reports. Twopir Consulting designs, builds and supports the integration between them: the data model, the mappings, the sends and the operating routine described on this page. Product behaviour is documented in SurveyMonkey's help center for SurveyMonkey for Salesforce.
Do you need a partner for it? A Salesforce admin can connect the app and map one survey to one object. A partner earns its place when the decisions become structural: several surveys feeding the same objects, responses that must update existing records without creating duplicates, sends driven by record changes, sandboxes that have to stay in step with production, or response volumes that make the per-answer data model a storage question.
This page covers the Salesforce connection only. For the wider programme (survey design, rollout and governance) see our SurveyMonkey consulting and implementation services; for connecting SurveyMonkey to the rest of your stack, see SurveyMonkey integration services.
Every SurveyMonkey Salesforce integration is some combination of these flows. We design each one explicitly: which direction it runs, what it carries, and who in Salesforce consumes it.
A record meets your criteria, a Salesforce Flow fires, and the survey goes out: as a web link inside your own email template, or as a SurveyMonkey email or text invitation.
DirectionSalesforce → SurveyMonkey
Custom variables carry the Salesforce Record ID and other known values into the survey link, so the response knows which record it belongs to and the survey can pipe or branch on CRM data.
DirectionSalesforce → SurveyMonkey
Completed responses, and optionally partial ones page by page, are written into Salesforce, either as managed-package response records or as values in fields you chose.
DirectionSurveyMonkey → Salesforce
Answers update the record the survey was about: a satisfaction score on the Case, a reason on a closed Opportunity, a preference on the Contact, or a new Lead from a form.
DirectionSurveyMonkey → Salesforce
Once the data is on the record, Salesforce takes over: Flow creates the task, case or alert, and the score is there for reports. The follow-up is built in Salesforce, not inside SurveyMonkey.
DirectionInside Salesforce
Every mapping keeps an audit log of successful syncs and an error log of failures on SurveyMonkey's Mappings page. Someone has to own that log, and we agree who before go-live.
DirectionSurveyMonkey → your admin team
SurveyMonkey for Salesforce offers two ways to store responses. The managed package keeps the full submission; custom object mapping puts specific answers where your existing layouts and reports already look. The choice can be made question by question, and many programmes use both.
| Consideration | Managed package objects | Custom object mapping |
|---|---|---|
| Where answers land | Two package objects: SurveyMonkey Survey Response, one parent record per submission, and SurveyMonkey Response, one child record per answered question. | Fields you choose on any standard or custom object, such as Contact, Lead, Account, Opportunity, Case or a custom feedback object. |
| Setup effort | SurveyMonkey builds the mapping for you. The package installs from a link inside SurveyMonkey's mapping flow, not from AppExchange. | You build each mapping, and the target objects and fields must already exist and be writable by the integration user. |
| What it keeps | The full submission: survey, collector, response status, each question and answer, and NPS score and label fields on the child records. | Only the answers and metadata you map, shaped to fit the record they describe. |
| Links to records | Built-in lookups to Account, Case, Contact, Lead and Opportunity. Any other object needs a lookup field added to the Response object. | Lives on the record itself, or on a custom object you relate to whichever records you need. |
| Reporting | Native Salesforce reports through the "SurveyMonkey Responses" report type, once Allow Reports is enabled on both objects. | Appears in the reports, list views and page layouts your teams already use. |
| Best for | Keeping a complete, auditable response history in Salesforce, and surveys whose questions change over time. | A small number of answers that drive process: a score on the Case, a churn reason on the Opportunity, a consent flag on the Contact. |
| Watch for | Data volume from one child record per answer, and the field-level security, layout and report updates newer package versions need. | Blank fields when several surveys share one object, solved with a record type and page layout per survey. |
Whichever model you choose, responses become reportable inside Salesforce. Building the dashboards, metric definitions and BI views on top of them is covered by our SurveyMonkey data and analytics services.
A mapping is a small set of decisions: what to do with the record, how to find it, and what to write. These are the settings SurveyMonkey for Salesforce exposes, and how we normally use each one.
| Setting | What it does | How we use it |
|---|---|---|
| Create a new | Always creates a new record for each response. | Forms that should produce a new Lead or a new feedback record every time. |
| Update an existing | Finds the record with a query mapping and logs an error if none is found. It can optionally overwrite fields that already hold values. | Surveys sent from a known record, such as a closed Case, where a missing record should be an error, not a new record. |
| Update or create | Updates the record if the query finds it, otherwise creates one. | Mixed audiences, where some respondents are already in Salesforce and others are new. |
| Query mapping | Decides how the existing record is found. SurveyMonkey recommends a custom variable carrying the Salesforce Record ID; matching on a survey field such as email fails when duplicates exist. | Record ID by default. Email matching only where a duplicate rule guarantees one record per email. |
| Survey content or data | Writes answers and response metadata to fields. Any response field can map to one or more objects. | Mapped to fields with the right data type and picklist values, agreed with whoever owns the reports. |
| More data | Writes a static value on every response, such as a Record Type ID, a language or a "survey taken" flag. | Record types per survey, and flags that let Flow tell a survey response from a manual edit. |
| Partial responses | Syncs answers page by page as the respondent clicks Next, instead of only on completion. | Only where an abandoned answer is still worth acting on, because downstream automation has to cope with incomplete data. |
| Assignment rules | Lets a mapping disable active assignment rules when it creates or updates Accounts, Cases and Leads. | Decided with the team that owns routing, so a survey update never reassigns a Case by accident. |
SurveyMonkey for Salesforce documents three deployment options, and all three are started by a Salesforce Flow. Salesforce has blocked new workflow rules since February 2023, so every new survey trigger we build is a Flow, and we migrate older triggers when they need changing.
The survey link, with custom variables, is placed in your own Salesforce email template and sent by an email alert from a Flow. It is the option to use when Salesforce data drives piping or advanced branching.
SurveyMonkey builds a Salesforce Outbound Message for you; a Flow on the triggering object fires it, and SurveyMonkey sends the invitation.
Triggered the same way as email, once your SurveyMonkey Customer Success Manager has enabled it. The number comes from a phone field on the triggering object.
The package also includes a Lightning flow and Lightning components for in-the-moment surveys from an Account, Contact, Lead or Case, which are not available to accounts on SurveyMonkey's EU data center. Designing the programmes these sends belong to (post-case CSAT, renewal NPS, reminders and closed-loop escalation) is the work of our SurveyMonkey automation services.
Most stalled SurveyMonkey Salesforce projects stall on licensing, permissions or environments, not on mapping. We confirm all of these in discovery.
| Prerequisite | What it means for the project |
|---|---|
| SurveyMonkey plan | SurveyMonkey for Salesforce is an Enterprise add-on, obtained through SurveyMonkey Sales or a Customer Success Manager. |
| SurveyMonkey seat | On plans with Power and Casual seats, the person who sets up the integration needs an Enterprise Power seat. |
| Integration user | A dedicated Salesforce user owns the connection, so mappings survive staff changes. The Salesforce Integration user license can be used once the right permissions are enabled. |
| Target fields | Objects and fields must exist and be writable before mapping. SurveyMonkey cannot write to read-only fields. |
| Historical responses | Requested through your Customer Success Manager. Each sync covers one mapping action, one survey and one collector, cannot be cancelled once running, and can take up to 4 hours. |
| Sandboxes | Sandboxes connect separately. Mappings move to production with Copy to Account, without their sync data, and a sandbox refresh means reconnecting and copying mappings again. |
| Data center and language | Lightning flows and components are not available on SurveyMonkey's EU data center, and the integration setup screens are in English only. |
Survey responses are CRM data, and they meet the same sharing model, duplicate rules and storage limits as everything else in the org. These are the decisions a solution architect settles before the first mapping goes live.
Records the integration creates are written by the connected integration user, and Lead, Case and Account routing may or may not run.
A query on a survey field fails when duplicates exist; a query on the Record ID does not.
The package relates responses to Account, Case, Contact, Lead and Opportunity. Anything else needs a new lookup.
Newer package versions add response created and modified date fields that need field-level security, layout and report updates.
The managed package stores one parent record per submission and one child record per answered question.
Mapping several surveys to one custom object can leave blank fields on every record.
These are the use cases SurveyMonkey documents for its Salesforce integration, described the way we design them: what starts the survey in Salesforce, and where the answer has to end up.
A Case closes and a Flow sends the survey. The score lands on that Case, so Service Cloud reports show satisfaction by queue, agent and case type.
Onboarding complete, a delivery milestone, a renewal: each stage change on the record can send a short CSAT survey that writes back to the same record.
NPS surveys sent to Contacts, with the package's NPS score and label fields available to report by account, segment or owner.
Periodic surveys about the whole relationship, related to the Account as well as the Contact, so leadership sees sentiment per customer, not per ticket.
A closed Opportunity sends a win/loss survey, and the reason the buyer gives sits next to the reason the rep entered.
Campaign members receive a post-event survey, and responses relate back to their Contact or Lead so marketing can segment on what attendees said.
A SurveyMonkey form creates a Lead with "Create a new" or "Update or create", with routing decided by whether assignment rules stay on.
Short surveys on any record your process touches, including custom objects, mapped with a Record ID so each answer lands on the record it describes.
Six phases, built in a sandbox first and promoted to production only after the mappings have been tested against real records. The length depends on how many surveys, objects and sends are in scope, and we set it in discovery.
Which surveys exist, which records they describe, who acts on the answers, and what the SurveyMonkey plan, seats and data center allow.
DeliverableSurvey and record inventory, prerequisites confirmed
Managed package or custom mapping per survey, the six data model decisions, the integration user and the sandbox strategy, written down.
DeliverableMapping design and data model sign-off
Fields, record types, lookups, permissions and the integration user prepared in Salesforce; custom variables added to the surveys; package installed where used.
DeliverableConfigured sandbox and surveys
Mappings, query rules and static values built, and the Flows, email alerts or Outbound Messages that send each survey.
DeliverableWorking sends and mappings in sandbox
Test responses for every path: matched, unmatched, duplicate, partial and permission errors. Admins are trained on the error and audit logs.
DeliverablePassed test set, trained admins
Mappings copied to production, historical sync requested where needed, then troubleshooting, tuning, updates and reconnection after sandbox refreshes.
DeliverableLive integration and support runbook
SurveyMonkey for Salesforce covers most survey-to-record needs through configuration. When the requirement goes beyond the packaged app, or beyond Salesforce, the work moves to a different service, and we say so early.
When survey data also has to reach HubSpot, Slack, Teams or a data warehouse, the architecture across all of them is our SurveyMonkey integration services.
Webhooks, bulk response retrieval or middleware the app cannot provide are built on the SurveyMonkey API by our SurveyMonkey API and custom integration services.
Escalation rules, follow-up cadences and detractor routing across teams are designed by our SurveyMonkey automation services.
Metric definitions, dashboards and BI on response data are the work of our SurveyMonkey data and analytics services.
Choosing the storage model, matching on Record ID, writing to custom objects, record types per survey, Flow-triggered email and text sends, historical sync and sandbox promotion are all configuration of SurveyMonkey for Salesforce and Salesforce itself.
We deliver them that way, because configuration is what your admin can maintain.
Transforming answers before they land, writing to a system the app does not reach, or reacting to response events in real time outside Salesforce.
That work uses the documented SurveyMonkey API and standard Salesforce patterns, never changes to the managed package.
We have not published a SurveyMonkey case study. The two engagements below are Salesforce builds where the same discipline applied: outside data landing on the right record, routed to an owner and reported on. They are shown for that discipline, not as SurveyMonkey deployments.
Lead capture, routing and pipeline reporting rebuilt on Salesforce, so every inbound record reached the right owner and showed up in the numbers.
Read the Sales Operations StudySeveral third-party systems brought into one Salesforce process, with a clean data flow between them.
Read the Integration StudyComparing survey tools inside Salesforce first? Read our guide to surveys in Salesforce, or see how we work with GetFeedback and Survey Force. More engagements are in our success stories.
The hard part of this integration is on the Salesforce side: ownership, sharing, duplicates, storage and automation. That is the part most survey projects underestimate, and the part we specialise in.
We start from the records your teams work and report on, then decide how survey data reaches them, rather than mapping whatever the survey happens to ask.
Duplicates, missing Record IDs and old responses are normal. Matching rules, error handling and historical sync are part of the design, not a clean-up project after launch.
Survey sends and record updates have to coexist with the Flows, validation rules and assignment rules already in your org. We check those interactions during the build.
If a Salesforce-native survey tool or a plain form fits better, we will say so in discovery. We work across the feedback and forms ecosystem, not only one vendor.
Troubleshooting, mapping tuning, package updates and sandbox reconnection, on a dedicated integration account, as part of our integration services.
Through SurveyMonkey for Salesforce, SurveyMonkey's own app, which is an Enterprise add-on. It connects to your Salesforce org over OAuth 2.0 and writes each response either into its managed-package response objects or into fields you map on any standard or custom object. Surveys can be sent from Salesforce when a Flow fires, by web link, SurveyMonkey email invitation or text.
Contacts, Leads, Accounts, Opportunities, Cases and custom objects. With the managed package, responses relate to Account, Case, Contact, Lead and Opportunity through built-in lookups, and other objects need a lookup field added. With custom object mapping, answers are written to fields on whichever standard or custom object you choose, and each mapping can create a record, update an existing one, or update it if found and create it if not.
The managed package keeps the full submission, with one parent record per response and one child record per answered question, and reports through the SurveyMonkey Responses report type. Custom fields fit the layouts and reports your teams already use. The choice can be made question by question, and the deciding factors are usually reporting needs and data volume.
Yes. A Salesforce Flow sends the survey when a record meets your criteria: as a web link in your own email template through an email alert, or as a SurveyMonkey email or text invitation fired by an Outbound Message that SurveyMonkey builds for you. Text sends must first be enabled by SurveyMonkey. Because Salesforce no longer allows new workflow rules, new triggers are built in Flow.
SurveyMonkey for Salesforce is an Enterprise add-on, obtained through SurveyMonkey Sales or your Customer Success Manager. On plans with Power and Casual seats, it needs an Enterprise Power seat. If your account is on SurveyMonkey's EU data center, note that the package's Lightning flows and components are not available there.
Yes, with SurveyMonkey's help. By default only responses collected after a mapping is created are synced. Older responses are synced on request through your SurveyMonkey Customer Success Manager, one survey, collector and mapping action at a time; completed responses are included, partial ones are optional, and a running sync cannot be cancelled and can take up to four hours.
Troubleshooting failed syncs from the error log, tuning mappings, applying package updates and the field-level security they need, and keeping mappings on a dedicated integration account. When a sandbox is refreshed, we reconnect it and copy the mappings across so testing keeps working.
A first conversation covers which surveys you run, which Salesforce records they describe, your SurveyMonkey plan and data center, and where responses get lost today: enough to recommend a mapping model and outline what the integration would take. No obligation to proceed.
Talk to a Salesforce architect who integrates SurveyMonkey
