Migrate from Bento to Salesforce Sales Cloud

Bento's flat Contact records require a split into Salesforce Account and Contact. If the Bento contact has a company name in a standard property, we create a Salesforce Account first and attach the Contact. Contacts without a company name get a singular Account (Company: Contact Email Domain) created automatically so that every Contact has an Account parent. Email address becomes Contact.Email, first and last name map to FirstName and LastName, and all Bento custom fields become typed Salesforce custom fields on Contact. Unsubscribed and bounced contacts migrate with DoNotCall and HasOptedOutOfEmail flags set, not as active records.

Bento contacts that represent unqualified prospects (no active sales relationship, no account context) may optionally map to Salesforce Lead if the customer prefers to stage prospects separately. We apply this mapping only when the Bento contact's custom properties indicate a sales-readiness state (e.g., a 'lead_status' custom field with a 'new' or 'prospect' value). Otherwise, Bento contacts migrate directly to Salesforce Contact under an Account. The customer chooses this strategy during scoping.

Bento's flat tag taxonomy (comma-separated label strings on each contact) migrates to a Salesforce multi-select picklist custom field on Contact. We export the full tag vocabulary, count tag frequency across the contact base, and recommend a tag consolidation strategy if the taxonomy exceeds Salesforce's 500-character multi-select limit. Tags used for behavioral classification migrate as picklist values; tags used for organizational purposes migrate as Contact.OwnerId assignments or Salesforce Topics with TopicAssignment records.

Bento Segments are dynamic filter rules against contact properties and behavioral events. We export segment definitions as structured rule documents (field, operator, value for each condition) and rebuild equivalent Salesforce List Views or Campaigns with Member Status filtering. For segments used in Bento automations, we document the segment membership criteria so the automation rebuild in Salesforce Flow can use the same filter logic. Segments that depend on Bento Custom Events require the corresponding custom field to exist on the Salesforce Contact first.

Bento custom fields are first-class properties with explicit data types (string, number, date, boolean, choice). We map data types 1:1 to Salesforce custom field types: Bento string to Salesforce Text, Bento number to Number or Currency, Bento date to Date, Bento boolean to Checkbox, Bento choice to Picklist. We pre-create every custom field in the destination Salesforce org before migration so that the import maps cleanly. Validation rules and picklist value sets are recreated from Bento choice field options.

Bento Campaigns represent one-time email sends with subject, HTML content, send history, and performance stats (opens, clicks, bounces). We migrate Campaign metadata to Salesforce Campaign records: Campaign Name, Type (Email), Status, StartDate, and description. HTML content is exported as a raw text blob for use in rebuilding in Salesforce Content Builder or a third-party email tool (e.g., Marketing Cloud Content Builder). Campaign performance statistics are preserved as Campaign statistics fields if manually entered, or as a summary document if the source data is aggregate-only.

Bento Automations are triggered behavioral flows built with a visual builder using conditions, delays, and action nodes. We export each automation as a structured migration brief: trigger type, condition nodes, delay settings, action nodes, and the contacts or segments in scope. This brief serves as the specification for rebuilding equivalent logic in Salesforce Flow. We do not export Bento automation logic as executable rules because Bento uses a proprietary flow format that cannot be parsed into Salesforce Flow XML or the Flow Builder format. Rebuilding is a manual step documented in the automation handoff package.

Bento Custom Events track behavioral signals (event name and property schema) attached to contacts. We export the full event schema (event name, property names, property data types) and the event log per contact. For standard Salesforce editions, each Bento Custom Event maps to a custom field on Contact with the event name embedded in the field label (e.g., 'Event: purchased_plan' becomes Custom_Event_purchased_plan__c with a timestamp and property payload stored in a Long Text Area field). For Salesforce orgs with Event Monitoring licensed, we map to the Event Monitoring event log format. Any incompatible property types are flagged during scoping for manual resolution.

Bento's unsubscribed suppression list migrates as Salesforce Contact records with HasOptedOutOfEmail set to true and a custom Compliance_Hold__c record linking to the original Bento unsubscribe timestamp and source (form, campaign, manual). We export unsubscribes as a separate CSV during scoping and apply the suppression flags before any active contact import begins, ensuring no re-activation of suppressed addresses in Salesforce. The Compliance_Hold__c object is a custom object that tracks the reason and date for audit purposes.

Bento's bounced suppression list migrates to Salesforce Contact records with DoNotCall set to true, EmailBouncedReason populated from the Bento bounce type (hard bounce or soft bounce), EmailBouncedDate set to the original bounce timestamp, and a Compliance_Hold__c record for audit. Hard bounces prevent any further email sends; soft bounces are noted but contacts may remain eligible for re-send after manual review. This prevents known invalid addresses from entering the Salesforce sending queue.

Bento's transactional email uses drop-in SDKs (Rails, Laravel, Node, Python, Go, PHP). API credentials, sending domain configuration, and template IDs are documented in a transactional email reconfiguration brief. Salesforce does not natively replace Bento's transactional email SDK, so the customer chooses a replacement (Salesforce Transactional Messaging API, SendGrid, Postmark, etc.) and we provide the documented configuration values from Bento for re-entry in the chosen platform. This is not a data migration; it is an engineering configuration handoff.

Bento's connected integrations (Shopify, WooCommerce, Zapier, and any other API-connected tools) are listed in a configuration export: integration name, data direction (read/write), and what data flows between Bento and each tool. We document the equivalent Salesforce integration path for each active connection. For Shopify and WooCommerce, Salesforce's B2C Commerce Integration or a native connector is documented as the replacement. For Zapier-based automations, the equivalent is documented as Salesforce Flow triggers or outbound messaging. This is an inventory, not a migration; each integration requires separate reconfiguration post-migration.