Migrate from Knack to Salesforce Sales Cloud

Every Knack Table maps to one Salesforce object — a standard object (Account, Contact, Lead, Opportunity) or a pre-provisioned custom object (__c). We reverse-engineer the full Knack Table inventory during discovery, including any Tables used only as junction (many-to-many) or parent-child (one-to-many) structures. Salesforce custom objects receive API names derived from the Knack Table name with a __c suffix. We provision the Salesforce schema (fields, lookups, record types) in a Sandbox org before any data migration begins.

Standard Knack field types map 1:1 to equivalent Salesforce field types. Currency fields in Knack may use a currency code; we preserve it in a separate custom field if Salesforce multi-currency is not enabled. Phone fields preserve E.164 formatting when present and strip formatting artifacts when they exist from freeform data entry.

A Knack Connection field linking Table A to Table B maps to a Salesforce Lookup field on the destination object for Table A, pointing to the Salesforce object mapped from Table B. The relationship cardinality is preserved. We resolve the foreign key at migration time by fetching Knack record IDs for the connected Table and mapping them to the corresponding Salesforce record IDs created during the parent-table migration phase.

Knack supports many-to-many relationships through a dedicated junction Table with two Connection fields. We identify these during schema discovery and map them to a Salesforce custom junction object with two Lookup fields — one to each related object. Every Knack junction row becomes a junction object record with both foreign keys resolved to the migrated Salesforce IDs.

A Knack Connection field that links a Table to itself (e.g., employee-to-manager, product-to-component) maps to a Salesforce custom field. We evaluate whether to use a standard Lookup(self) or a hierarchical relationship depending on the business meaning. Self-referencing relationships require careful cycle detection during migration to avoid insert-order loops.

Knack file fields (documents, images, PDFs) are accessed via authenticated URLs. We download each file from Knack, upload it to Salesforce as a ContentVersion record, and create a ContentDocumentLink linking it to the parent Salesforce record (Contact, Account, custom object). File names and MIME types are preserved. We handle both inline-display images and downloadable attachments. Large files (>12 MB) exceed Salesforce REST API single-upload limits and require multipart chunked upload via the API.

Knack equation fields compute values from other fields within the same record. We migrate the computed values as read-only custom fields on the Salesforce object, noting the original equation logic for the customer's admin to rebuild as a Salesforce formula field post-migration. Formula logic itself does not migrate because Salesforce formula syntax differs from Knack equation syntax.

Knack Views are saved filtered or sorted subsets of a Table exposed to end users. We document every View's filter conditions and sort order. Salesforce List Views replicate the filter logic natively. For Views with complex Knack display rules (columns shown, column order, grouping), we note them as a configuration task for the customer's admin post-migration.

Individual Knack records (rows) migrate to Salesforce records on the mapped object. We export all records via the Knack Object API with pagination, checkpoint each page, and validate total record counts against Knack's UI-visible count before closing the export phase. Knack Record IDs are preserved as an external ID field (e.g., knack_record_id__c) to support re-import and cross-reference after migration.

Knack roles control Page and Record access. We export role names and permission scopes as metadata. The mapping to Salesforce Profiles and Permission Sets is conceptual: a Starter-tier Knack role maps to a Salesforce Profile with object-level access, and a Pro-tier role with record-level scoping maps to Permission Sets. The customer reviews and finalizes the permission mapping in their Sandbox before production migration.

Knack Automation Workflows (email notifications, field updates, record creation triggers, conditional logic) have no direct Salesforce equivalent that migrates as code. We document every active Knack Workflow in a separate handoff sheet: trigger object, conditions, actions, and a recommended Salesforce Flow equivalent. The customer's admin or a Salesforce partner rebuilds them post-migration. This is out-of-scope for data migration.

Knack Scheduled Tasks (Pro and above) run background jobs at defined intervals. We flag their existence, document the schedule, and note the business function they perform. Rebuilding them in Salesforce Flow (Scheduled Flow type) is an admin task post-migration. This is out-of-scope for data migration.

Knack Record History (available on Pro at 1 month, Corporate at 2 months) tracks field-level changes. We export available history as a JSON blob stored in a custom long-text area field on the Salesforce record, tagged with the field name, old value, new value, and timestamp. If Salesforce Field History Tracking is enabled on the object, we activate it going forward. Historical history from Knack does not populate Salesforce's native Field History tracking retroactively.

Healthcare deployments on Knack Health involve PHI requiring a signed BAA. We handle PHI migration under additional security controls: encrypted transfer, no logging of PHI values, and a post-migration BAA handoff note documenting which fields contained PHI, their Knack data classification, and recommended Salesforce Field Level Encryption or Custom Metadata configuration. This work is scoped separately from standard migration.