Migrate from Rizer to Salesforce Sales Cloud

Rizer's Contact object holds both prospect and customer records with referral attribution embedded as custom fields. We split on Rizer's lifecycle stage and referral source: Contacts with no closed Deal map to Salesforce Lead; Contacts with a closed Deal or active pipeline map to Salesforce Contact attached to an Account. Referral source and attribution window migrate to custom fields on both Lead and Contact (e.g., referral_source__c, attribution_window__c) for audit and reporting continuity.

Rizer Company records (linked to Contacts via company association) map directly to Salesforce Account. The domain or website field from Rizer becomes the Account Website field and serves as the dedupe key during import. Account is created before Contact import so that the AccountId lookup is satisfied at the moment of Contact insert.

Rizer Deals map to Salesforce Opportunity. The deal stage from Rizer maps to a Salesforce StageName that we configure as part of the destination schema, with probability percentages migrated from Rizer's stage settings. Rizer does not enforce multiple pipelines, so a single Opportunity Record Type covers the migrated Deals unless the customer requests pipeline segmentation.

Rizer custom fields on Contact (key-value pairs returned by the Referrizer API) migrate to typed Salesforce custom fields. We inspect raw values before writing to infer data type: date strings become Date fields, delimited text becomes Multi-Select Picklist or Text, numeric text becomes Number. Rizer does not enforce type constraints at export time, so type inference is the critical step to avoid silent coercion errors in Salesforce validation rules.

Rizer's referral tracking sources, attribution windows, and referral campaign names are stored as Contact properties. These have no Salesforce standard field equivalent. We create custom fields referral_source__c (Text), attribution_window__c (Date), and referral_campaign__c (Text) on both Lead and Contact. Attribution history spanning multiple campaigns maps to a custom related object (Referral_History__c) if the customer's attribution model requires it.

Rizer Workflows attached to Contact records are email sequences with branching logic, delay rules, and tag triggers. We extract workflow names, trigger conditions, and action steps as a written inventory document with recommended Salesforce Flow equivalents. We do not migrate workflow logic as code because Salesforce Flow has a different action model and trigger architecture. The customer's admin rebuilds active workflows post-migration.

Rizer tags applied to Contacts are flat string lists. These migrate to Salesforce custom picklist fields on Lead and Contact. If the customer uses tags for content classification or segmentation, we map to Salesforce Topics with TopicAssignment records. The customer chooses tag strategy during scoping because some teams prefer multi-select picklist (no additional object) while others prefer Topics (enables topic-based reporting).

Rize Clients (from the separate time-tracking product at rize.io) map to Salesforce Account. Clients belong to the Rize product with a separate login and API domain from Rizer Social. We treat Rize as a second export scope and do not assume the same API endpoint covers both products. If the customer uses only Rizer Social, this mapping is skipped.

Rize Projects belong to Clients and contain Tasks. Rizer does not have a native project concept; this is Rize-only data. Projects map to Salesforce Opportunity if they represent billable engagements, or to a custom Project__c object if the customer needs project-level tracking without deal semantics. Sub-tasks from Rize become discrete Task records with a ParentTaskId reference in Salesforce.

Rize Tasks nested under Projects map to Salesforce Task records. Rize subtasks (stored as a boolean or count field on a Task) expand into discrete Salesforce Task records with IsSubtask = true and a ParentTaskId reference. Task time entries from Rize become Salesforce Task fields or a custom Time_Entry__c object depending on the customer's billing workflow.

Rizer and Rize Team Members map to Salesforce User records. We resolve by email match against the Salesforce org's User table. Role assignments (admin, manager, member) map to Salesforce UserRole and Profile. Any Rizer Team Member without a matching Salesforce User goes to a reconciliation queue for the customer's admin to provision before record import proceeds.

Rizer email engagements migrate to Salesforce EmailMessage records linked to a Task (the activity timeline entry). The WhoId on Task points to the migrated Lead or Contact; the WhatId points to the related Opportunity or Account. Email content and timestamp preserve; attachments migrate as ContentDocument records linked via ContentDocumentLink.

Rizer call engagements map to Salesforce Task with TaskSubtype = Call. Call disposition, duration, and any recording URL transfer to custom Task fields. Activity timeline ordering is preserved by setting ActivityDate to the original Rizer timestamp. We use the Bulk API for call record migration to handle volume without timeout.

Rizer meeting engagements map to Salesforce Event with StartDateTime, EndDateTime, and Location preserved. Attendee records link to EventRelation records pointing at the migrated Leads, Contacts, and Users. Meeting notes migrate as Salesforce Note records attached via ContentDocumentLink to the Event.

Rizer Notes (engagement type NOTE) migrate to Salesforce Note records linked via ContentDocumentLink to the parent Lead, Contact, Account, or Opportunity. Note body migrates as rich text with any embedded images preserved as separate ContentDocument records.

Rizer task engagements map to Salesforce Task with Status, Priority, and ActivityDate preserved. Task assignment migrates by resolving the Rizer owner reference to Salesforce OwnerId via the User mapping. Overdue status and completion timestamps carry through as custom fields if the customer requires the full task lifecycle in Salesforce.