Migrate from Legl to Salesforce Sales Cloud

Legl's Organisation is the root entity containing firm-wide settings, AML configuration, and compliance rules. We map it to a single Salesforce Account record. The org_id field becomes Source_Org_ID__c for traceability. Settings like AML configuration that have no Salesforce standard equivalent are stored as Org_Settings__c custom long-text area on the Account.

Legl Business records represent client law firms or individual clients. The primary contact within each Business maps to a Salesforce Contact linked via AccountId. Additional contacts from the same Business become additional Contact records with the same AccountId. Business-level KYC status (Source_KYC_Status__c), industry, and country fields map to custom fields on the Account.

RiskAssessment objects carry the assessment type, status, risk_level, risk_score, and a PDF output URL. We create a Risk_Assessment__c custom object in Salesforce with fields for each Legl property. The PDF URL triggers a re-upload as a Salesforce File (ContentVersion), linked to the Risk_Assessment__c record via ContentDocumentLink, preserving the original filename and create timestamp from Legl.

Legl Payment records contain amount, currency, status, and a Stripe checkout_url. We create a Payment__c custom object in Salesforce with Amount__c (currency), Currency__c, Payment_Status__c, Stripe_Reference__c (stored as an external ID for Stripe reconciliation), and Checkout_URL__c. Each Payment__c links to the Account representing the associated Business.

EngageRequests track client due diligence workflows: request type, status, assigned reviewer (Contact), and CDD stage. We create an Engage_Request__c custom object with custom fields for type, status, reviewer (lookup to Contact), CDD stage, and timestamps. The Legl workflow type and status pick-list values are mapped to Salesforce custom picklist value sets.

Legl stores workflow definitions as JSON documents retrieved via the Engage /workflows endpoint, specifying steps, reviewers, and branching conditions. These definitions have no native Salesforce equivalent — Salesforce Flow uses a separate declarative or Apex-based model. We export every Legl workflow definition as a JSON reference document delivered alongside the migration data so your Salesforce admin can rebuild the logic in Flow or Apex.

Legl's reviewer list (Contact-type users) maps to Salesforce Contacts with a custom reviewer flag. If the reviewer is an internal Legl user who will also be a Salesforce user, we match by email to the Salesforce User record and store the link in a custom reviewer lookup on the Engage_Request__c. External-only reviewers remain as Contacts.

Legl's Ongoing Monitoring configuration tracks continuous compliance checks. We map this to a Monitoring__c custom object with fields for the monitoring type, status, and next review date. The object links to the Account representing the monitored Business. The Monitoring__c object also stores the last audit date and a link to the associated compliance report, enabling a complete audit trail within Salesforce.

Legl company and sanctions reports are stored as report objects with status and reference fields. We create a Compliance_Report__c custom object with report type, status, and Legl report ID as an external reference. If the report includes a PDF, it is re-uploaded as a Salesforce File linked to the Compliance_Report__c record.

Legl file attachments (PDFs, documents) retrieved via the API are re-uploaded to Salesforce as ContentVersion records and linked to the appropriate parent record via ContentDocumentLink. The original filename, mime type, and create date from Legl are preserved in Salesforce File metadata.

Legl's original createdate and updatedate timestamps on every object do not map to Salesforce's CreatedDate or LastModifiedDate (both are set at migration time). We preserve all original Legl timestamps as custom datetime fields (e.g., Legl_Created_Date__c) for audit continuity and reporting accuracy.