Migrate from APSIS One to Salesforce Sales Cloud

APSIS One Profiles with no associated CRM account association and no purchase event history map to Salesforce Lead. Profiles with an associated CRM contact record, purchase event, or active subscription map to Salesforce Contact tied to an Account. We evaluate the split using APSIS One's has_email_consent, last_purchase_date, and integration_source properties. The original APSIS One Profile ID is preserved in a custom field apsis_profile_id__c on both Lead and Contact for audit and cross-reference. This split must be defined during scoping because it determines the entire record hierarchy (Account -> Contact vs flat Lead pool).

Standard APSIS One Attributes (email, first_name, last_name, phone, city, country, date_of_birth) map to the equivalent standard Salesforce fields with direct type matching. Email becomes Email on Contact or Lead; phone becomes Phone; date_of_birth becomes Birthdate. We validate field-level type compatibility during scoping and flag any attribute with a mismatched destination type (e.g., a date stored as string in APSIS One) for pre-import transformation.

Custom Attributes in APSIS One have no enforced schema and no fixed data type declaration in the export payload. We inspect each custom attribute's value type at export time (string, number, boolean, date, array) and map it to the nearest Salesforce field type: text fields become Text(255), long text becomes Text Area(Long), numeric values become Number, dates become Date, arrays become Multi-Select Picklist or Text(255) depending on array length. Custom fields are pre-created in the destination org via the Salesforce metadata API before the first data import phase begins.

APSIS One Tags are flat string labels applied to Profiles. Tags used for contact classification (e.g., VIP, churned, newsletter) migrate to Salesforce Contact Labels if the destination org uses the Lightning Contact Labels feature. Tags used for segmentation criteria migrate to a Multi-Select Picklist custom field apsis_tags__c. The customer selects the tag strategy during scoping based on their use of Labels in other downstream tools (e.g., Salesforce Pardot).

Behavioral events logged against a Profile (purchase, page_view, form_submit, email_open, email_click) map to Salesforce Task records with a custom event_type__c field carrying the original APSIS One event name and event_properties__c carrying the JSON payload. Events with timestamps older than 24 months can optionally be summarized as aggregate records to reduce import volume if the customer does not require full event-level history in Salesforce. Large event histories are paginated under the 100 kB body ceiling per Profile before transformation.

APSIS One Segments are audience groupings exported via the Profiles in Segment Report endpoint. Static segments map to Salesforce Campaigns of type Static. Dynamic segments (rule-based, updating in real time) cannot be migrated as live-updating entities; we deliver the segment rule definition as a written document describing the rule conditions, operators, and value sets, and the customer's admin rebuilds the equivalent as a Salesforce Campaign with manual membership or a Flow-triggered Campaign membership rule. Segment membership count is preserved in a custom field on the Campaign for reference.

APSIS One Consent 2.0 stores channel-specific consent with timestamps on each Profile. We preserve consent flags per channel (email_consent, sms_consent, push_consent) as custom fields consent_email__c (boolean + date), consent_sms__c (boolean + date), and consent_push__c (boolean + date). Email consent also populates Salesforce's standard HasOptedOutOfEmail field inversely (HasOptedOutOfEmail = false means consent granted). Consent records are migrated first, before any marketing campaign data, to ensure re-permissioning is not required post-migration.

APSIS One Marketing Automation Canvas Flows have no public API for export. We capture Flow definitions during the discovery call as screenshots, trigger descriptions, action step summaries, and condition branch logic. We deliver a written Flow Inventory document mapping each APSIS One Flow to a recommended Salesforce Flow type (record-triggered, scheduled, or screen) with the equivalent trigger conditions and action steps. The customer's Salesforce admin or a certified partner rebuilds each Flow in Flow Builder. Multi-branch flows with more than five conditions require prioritized sequencing because they have the longest rebuild time.

APSIS One bi-directionally syncs Contacts, Accounts, and Deals from Efficy Enterprise, Microsoft Dynamics 365, Lime CRM, and webCRM. The sync state is not accessible via the public API. We export the current Profile data and the integration configuration (connection credentials and field mapping) as documentation. After cutover, the customer re-pairs the CRM connector in Salesforce and triggers a full resync to repopulate sync metadata in the destination. The APSIS One Profile ID is preserved in a custom field for cross-referencing during the resync window.

APSIS One Sections are organizational units holding Segments and Flows. We map Sections to Salesforce Campaign Folders (parent folder hierarchy) with Campaigns nested under the corresponding folder. If the destination org does not use Campaign Folders, we map Sections directly to Campaigns and use the Campaign Description field to carry the Section context.

APSIS One channel configurations (email sending limits: 2M emails/hour; SMS sending limits: 1M SMS/hour) are account-level settings and do not map to per-record Salesforce fields. Channel preferences stored on individual Profiles (e.g., preferred_contact_channel = email or SMS) migrate as a custom picklist field preferred_channel__c on Contact or Lead. The account-level sending infrastructure limits are documented in the migration handoff for the customer's Salesforce admin to configure in Salesforce Marketing Cloud if sending infrastructure is also migrated.

APSIS One does not expose a dedicated Owner object via the public API; owners are referenced by email on Profile export. We extract every distinct owner email and match by email against the Salesforce destination org's User table. Owners without a matching Salesforce User go to a reconciliation queue. The customer's Salesforce admin provisions any missing Users before record import resumes. Owner references on Events (activity history) are resolved through the User mapping after the primary Contact and Lead import completes.