Migrate from RollWorks Account-Based Platform to Salesforce Sales Cloud

RollWorks Account Lists map to Salesforce Account records. The Account List membership is captured as a custom Account field (rollworks_account_list__c) plus the list name, and we preserve any firmographic enrichment data attached to the account in RollWorks. The RollWorks website field becomes the Account Website field and serves as the dedupe key during import — we validate website completeness and format before migration because RollWorks uses it to match companies against its database. Records missing a website value are flagged for enrichment or manual review before the Account import begins.

RollWorks Account Groups (collections of Account Lists used to segment campaigns and reporting) map to Salesforce Campaign records with hierarchical folder structure matching the original group membership. We preserve the group-to-list relationships as Campaign Member records keyed to the Account IDs, and we document the Account Group hierarchy so it can be reconstructed in Salesforce as a folder-and-segment structure. If the destination org already has Campaigns, we avoid naming collisions by prepending the RollWorks group name during import.

Journey Stages in RollWorks are derived from CRM field values ingested through the Salesforce integration — they are read-only derived values, not independently authored in RollWorks. During migration, we capture the current Journey Stage assignment for each account as a custom text field (rollworks_journey_stage__c) on the Account record. We flag any accounts where the Journey Stage was driven by a custom Salesforce object or custom field that will not exist in the destination org — those accounts are noted separately for manual Salesforce admin review and Journey Stage reassignment after migration.

RollWorks writes aggregated engagement metrics (fit score, intent score, engagement score, spend, impressions, clicks, conversions) back to a custom Salesforce object during its bidirectional sync. When migrating away from RollWorks, this custom object data must be extracted via API and recreated as custom fields on the standard Account object and, where applicable, on the Campaign object. We perform this extraction as a separate API pass before disconnection, mapping the custom object fields to new Salesforce custom fields on Account (adroll_fit_score__c, adroll_intent_score__c, adroll_engagement_score__c) and Campaign (adroll_spend__c, adroll_impressions__c, adroll_clicks__c). Legacy object naming from pre-February 2026 package versions may still reference 'RollWorks' — we identify and handle these during scoping.

Hot Contacts (deanonymized web visitors pushed to CRM as leads or contacts via workflow actions) migrate to Salesforce as Lead records (for new prospects) or Contact records (for known contacts). We extract the Hot Contact assignment, status, and engagement history from RollWorks, and we check whether any of these contacts are currently Leads in Salesforce that should be converted to Contacts before migration — if so, we flag the Lead-to-Contact conversion gap for the customer's admin to resolve before the engagement history import runs.

Playbooks are automation sequences defined in the AdRoll ABM orchestration layer with triggers (CRM field changes, audience entry, ad engagement thresholds) and actions (CRM updates, email sends via Marketo or HubSpot, Hot Contact alerts). We perform a dedicated Playbook extraction pass to capture every active Playbook with its trigger conditions, audience criteria, action sequence, and step timing. We deliver this as a written Playbook inventory with recommended Salesforce Flow equivalents. Playbooks do not migrate as code because AdRoll's execution layer has no Salesforce Flow analog. The customer's admin rebuilds the automation logic in Flow post-migration.

RollWorks Sales Insights surface accounts spiking in engagement with a predicted two-times likelihood of becoming opportunities. These scores are written to the Salesforce or HubSpot widget during the sync. We extract the signal fields (spike strength, contributing channels, spike timestamp) as custom fields on the Account record (adroll_spike_strength__c, adroll_spike_channels__c, adroll_spike_date__c) so that the sales team's prioritization data is available as a sortable Account field after migration. The spike ranking logic is preserved as field values rather than as an automated scoring engine.

RollWorks Audiences are built from RollWorks' own data and CRM field combinations using the platform's filter builder. Because RollWorks' filter capabilities are limited compared to dedicated data platforms (a constraint cited in 45 G2 mentions), teams often have relatively contained segmentation rules. We document every active Audience Segment with its filter logic, ICP matching criteria, and data source (RollWorks proprietary, Bombora Intent, G2 Intent, CRM field). This segmentation audit is delivered to the customer's admin for reconstruction in Salesforce's Campaign segmentation tools, Account Lists, or a third-party data platform if more granular segmentation is required post-migration.

Campaign structure (campaign names, ad sets, creative configuration, audience targeting rules) lives in RollWorks' advertising layer and does not migrate as live ad creative assets. We extract campaign configuration, audience targeting rules, and historical performance metrics (impressions, clicks, spend, conversions) via the NextRoll GraphQL Reporting API and write them as custom fields on the corresponding Salesforce Campaign record (adroll_spend__c, adroll_impressions__c, adroll_clicks__c, adroll_conversions__c). The advertising creative itself remains in AdRoll ABM; if the team continues using AdRoll for advertising, these metrics feed back via the Salesforce integration. If the team moves to a different advertising platform, the historical RollWorks campaign performance data is preserved in Salesforce for reporting continuity.

Contact Audiences in RollWorks are built from CRM Contact records synced via email. The email field on the Contact object is converted to cookies for Contact Targeting campaigns. We migrate the Contact record assignments and the RollWorks audience membership status (ready, engaged, etc.) as a custom field (adroll_audience_status__c) on the Salesforce Contact so that the team knows which contacts were in active RollWorks audience workflows before migration. The cookie-based targeting itself is AdRoll-specific and does not carry to Salesforce.

RollWorks ingests Lead records from the connected Salesforce org for Contact Targeting campaigns, converting email addresses to cookies for ad targeting. We migrate Lead records that were actively targeted in RollWorks with their advertising engagement history (impressions, clicks, ad attribution) as custom fields on the Salesforce Lead record. We flag any Lead records whose Journey Event activity could not be associated to an Account in RollWorks due to the Lead-to-Account association limitation — these Leads may have incomplete behavioral history in RollWorks that will not appear in Salesforce either.

Journey Events aggregate activity from Marketo, G2, and advertising engagement and associate it with Salesforce Contacts linked to Accounts. We extract Journey Event history as Activity records (Task and Event) linked to the Contact in Salesforce, preserving the event type, contributing channels, and timestamp. Lead object activity that could not be associated to Accounts in RollWorks is noted as a data gap — we flag these records and recommend a Lead-to-Contact conversion audit before migration so that the behavioral history is preserved against the correct Account record in Salesforce.