Migrate from Signpost to Salesforce Sales Cloud

Signpost Contact records with an associated Business map to Salesforce Contact tied to an Account. Signpost contacts that represent unqualified prospects (no closed deal, no appointment completed) may map to Salesforce Lead at the customer's direction. We preserve the original Signpost contact ID in a custom field signpost_contact_id__c and carry forward any custom properties (preferred contact method, referral source, customer tier) as typed Salesforce custom fields. Owner assignment resolves via email match to Salesforce User.

Signpost's Business records map to Salesforce Account. For multi-location customers, Signpost's Business hierarchy (parent Business with child locations) maps to Salesforce Account hierarchy with ParentAccountId resolved after the root Account is created. Business address maps to Account BillingAddress; business phone maps to Account Phone. Signpost Business name becomes Account Name.

Signpost Campaigns (email and SMS) migrate to Salesforce Campaign with Campaign Name, Type (Email or SMS), Status, and StartDate/EndDate preserved. Campaign content (body copy, subject lines) migrates as Salesforce Campaign Description. Contact membership in Signpost Campaign maps to Salesforce CampaignMember with Status mapped (subscribed, bounced, unsubscribed) to CampaignMember Status values. Mia's automated trigger logic (send timing, behavioral conditions) does not migrate and is documented separately for Flow rebuild.

Signpost's review solicitation records (request date, status, customer response, Mia flag) have no native Salesforce equivalent. We migrate the most recent review request status and response as two custom fields on Contact: signpost_last_review_request__c (date) and signpost_review_status__c (text: requested, positive, flagged, responded). Full solicitation history across all time requires flattening into a Signpost_Review_History__c custom object with one row per request, which we recommend for customers with high review volumes needing audit trails.

Signpost Appointment records (scheduling data, customer association, status, appointment type) map to Salesforce Task or Event depending on the customer's calendar strategy. Appointments with a specific start and end time map to Salesforce Event with WhoId (Contact) and WhatId (Account or Opportunity) populated. Appointments stored as task-like items map to Salesforce Task with ActivityDate. We flag any custom appointment types (service type, technician assignment) for custom field mapping during scoping.

Signpost Payments (a separate product tier) tracks payment status against invoices or estimates. Payment records migrate to a Payments__c custom object with fields for amount, status, date, and related Contact and Business lookups. If the customer uses Signpost's invoice-to-payment flow and Salesforce Opportunity is in scope, payment records attach as OpportunityLineItem entries tied to the relevant Opportunity. We note during scoping whether Signpost Payments is in use and whether Opportunity-level payment tracking is desired.

Signpost custom fields on Contacts and Businesses export as typed data. We map these to Salesforce custom fields using type-equivalent Salesforce field types: text fields to Text(255), numbers to Number, dates to Date, checkboxes to Checkbox, and multi-select values to Multi-Select Picklist. Any custom property that has no equivalent Salesforce type is flagged for customer review and mapped to a Long Text Area field as a fallback. Custom field API names are preserved with a signpost_ prefix during migration for audit traceability.

Signpost contact segments and tags used for campaign targeting migrate as Salesforce Campaign membership (for active campaign segments) or as multi-select picklist values on the Contact record (for behavioral tags such as service type, region, or customer tier). We flag any segment logic that relied on Mia's behavioral scoring for customer review, as that scoring model cannot be reconstructed without manual definition.

Referral program enrollment and loyalty point balances migrate as custom fields on Contact (enrollment status, referral code, loyalty tier) or as a Referral__c custom object with one record per enrollment and a lookup to the referring Contact. Program rules (point values, reward tiers, expiry logic) are not exportable and require manual setup in Salesforce or a loyalty app from the AppExchange.

Signpost user accounts and owner assignments on records map to Salesforce User by email match. Inactive Signpost users who are no longer with the company are held in a reconciliation queue; the customer's Salesforce admin decides whether to provision inactive placeholder Users or skip them entirely. Active users are provisioned against the Salesforce org before Contact and Account migration begins so that OwnerId references are valid at insert time.

Mia-driven workflow automations execute based on contact behavioral triggers, review request responses, and campaign engagement signals using proprietary scoring logic. These automations are not accessible via any documented export endpoint. We do not migrate them. At scoping, we collect a written inventory of every active Mia rule from the customer (trigger, conditions, actions, timing) and deliver a structured Workflow Audit Form that maps each rule to a recommended Salesforce Flow equivalent. The customer's admin or a Salesforce partner rebuilds the automation layer post-migration.

Signpost's shared inbox stores two-way customer conversations that are not accessible via export. Contact records, campaign history, and appointment data migrate cleanly. The message threads themselves are not recoverable. We flag this at the start of scoping and recommend customers screenshot or manually archive any critical threads before migration cutover. After cutover, ongoing message capture continues through Salesforce's native email integrations (Lightning for Gmail, Lightning for Outlook, Email-to-Case).