Migrate from Insightly Service to Salesforce Service Cloud

Insightly Tickets map directly to Salesforce Cases. Ticket status maps to Case Status using a status mapping table defined during scoping (Insightly OPEN/CLOSED/PENDING to Salesforce Case Status picklist values the customer selects). Ticket priority maps to Case Priority. We preserve the original Insightly ticket number as a custom field ins_ticket_number__c for cross-reference. SLA timer values from Insightly transfer to Salesforce Entitlement Processes and Milestones if the destination org has Service Cloud with Entitlements enabled; if not, SLA elapsed time is stored as a custom field sla_elapsed_hours__c for manual entitlement setup post-migration.

Ticket conversations (comments on Insightly Tickets) migrate to Salesforce EmailMessage records linked to the Case. Each comment becomes an EmailMessage with the author name, timestamp, and HTML body preserved. Inbound and outbound direction is inferred from the comment author (agent vs customer) using the contact lookup. EmailMessage records appear in the Salesforce Case's activity timeline, preserving the chronological conversation view that support agents rely on during case review.

Insightly Organizations map to Salesforce Accounts. The Organization name becomes Account Name, and industry classification maps to the Industry picklist. Address data transfers to the Account's billing address fields. We preserve the ORGANISATION_ID as ins_organisation_id__c for cross-reference and use it as the dedupe key during import. Account is created before any Ticket or Case import so that the AccountId lookup is satisfied at the moment of Case insert.

Insightly Contacts map to Salesforce Contacts with name, email, phone, and address fields transferred directly. The CONTACT_ID is preserved as ins_contact_id__c for cross-reference. If the destination Salesforce org uses Account hierarchy, we link each Contact to the Account derived from the Insightly Organization during import. Custom fields on Contact use the FIELD_NAME lookup from Insightly's /CustomFields/Contacts endpoint before import to avoid silent drops.

Insightly Agents (users who handle tickets) map to Salesforce Users. We resolve agents by email match against the Salesforce destination org's User table. Any Insightly Agent without a matching Salesforce User is held in a reconciliation queue for the customer's admin to provision before case import resumes. Active and inactive status is preserved via a custom field ins_agent_active__c.

Insightly Teams migrate to Salesforce Public Groups if the use case is visibility-based sharing, or to Omni-Channel Routing Queues if the destination org uses Omni-Channel for case distribution. The choice is made during scoping based on whether the customer wants queue-based routing. Team member assignments are preserved as GroupMember records linking Users to the destination Group or Queue. If Salesforce Service Cloud Omni-Channel is not enabled, we default to Public Groups.

Insightly custom field groups use FIELD_NAME identifiers (not display labels) that must be retrieved via GET /v3.2/CustomFields/{objectName} before any data is written. We enumerate every custom field definition for Tickets, Contacts, Organizations, and Projects during discovery, map the FIELD_NAME to the equivalent Salesforce API field name (with __c suffix for custom fields), and verify the field type compatibility. Type mismatches (Insightly date field vs Salesforce datetime field, for example) are flagged and corrected before migration begins. Insightly's custom field limits are Plus 50, Professional 100, Enterprise 200 per object; we validate that the destination Salesforce edition supports the migrated field count.

File attachments on Insightly Tickets and Organizations are exported as metadata (filename, URL, MIME type, size) via the Insightly attachments API. Files are downloaded to a staging environment and re-uploaded to Salesforce as ContentVersion records. Each ContentVersion is linked to the parent Case or Account via a ContentDocumentLink record with the ShareType set to I (Inferred) for the case-specific view. Attachments are imported after Cases and Accounts so the parent record IDs are available for linking.

Insightly Notes (standalone objects linked to Contacts, Organizations, Opportunities, or Projects) migrate to Salesforce Note records. We preserve the note body, author, and created date, and link via ContentDocumentLink to the parent Contact, Account, or Opportunity using the resolved ID from the import phase. If the destination org uses Salesforce Lightning, we map to ContentNote as well depending on the customer's preference for rich text vs classic notes.

Insightly Projects are CRM-level objects linked to Opportunities or Organizations. If the destination Salesforce org does not have a native project management object, Projects migrate to a custom Project__c object that we pre-create in the destination schema with the required fields (Name, Status, StartDate, EndDate, related Account, related Opportunity). If the customer uses Salesforce Field Service or a project management AppExchange package (Monday.com, Asana), we create the mapping to the appropriate destination during scoping. Project task sets migrate as related Salesforce Tasks linked to the Project record.

Insightly KB Articles (titles, body content, category assignments, and publish status) migrate to Salesforce Knowledge Articles. Category structure from Insightly maps to Salesforce Article Type and Data Category Groups. We migrate article titles, body HTML, and publish status; article view counts and feedback ratings are stored as custom fields on the Knowledge Article because they do not map to standard Salesforce Knowledge fields. KB article migration requires the Salesforce Knowledge feature to be enabled in the destination org before import.

Insightly Opportunities linked to Organizations migrate to Salesforce Opportunities with AccountId resolved from the Organization-to-Account mapping. Pipeline stage, deal value, probability, and close date transfer directly. Opportunity Categories use FIELD_NAME identifiers in Insightly; we map these to Salesforce Opportunity StageName using a stage mapping table. Closed-Lost and Closed-Won reasons from Insightly become Salesforce Loss Reason and custom win/loss fields. If the destination org uses multiple Sales Processes, we assign the appropriate Record Type per Opportunity during import.