Migrate from RealGreen by WorkWave to Twenty CRM

RealGreen customers map directly to Twenty People. The customer record holds name, email, phone, address, and service flags — all standard Twenty People fields. Original RealGreen customer IDs are preserved in a custom Source_System_ID__c field for delta-run de-duplication. Customers without an assigned company in RealGreen land as standalone People records in Twenty.

RealGreen company records (business accounts, property management entities) map 1:1 to Twenty Companies. Company name, domain, industry, address, and employee count translate to the corresponding Twenty Companies fields. RealGreen supports company hierarchies (parent/child); these map to Twenty's nested Companies structure via the parentId reference where applicable.

Work Orders have no native Twenty equivalent — they become a custom Work_Order object created in Settings → Data Model before import. The object holds technician name, service type, territory, scheduled date, status, total amount, and notes. Work Order ID is stored in Source_System_ID__c for traceability. RealGreen's open vs. completed vs. invoiced status maps to a Work_Order_Status__c pick-list.

Individual service lines on a Work Order (e.g., lawn mowing, mulching, aeration) are imported as child Work_Order_Line_Item records linked to the parent Work_Order via a relation field. Each line carries service name, quantity, unit price, and line total. If RealGreen uses bundled pricing, the bundle is stored as a single line with the aggregated amount and a line_description noting the bundle name.

RealGreen's assigned representative on a customer or work order is resolved by email match against Twenty workspace members. Unmatched owners are flagged with an Assigned_Rep_Source__c text field containing the RealGreen owner name and email, so the team can manually assign in Twenty post-migration. Twenty requires members to accept invitations before foreign-key relations can be established — this step is sequenced before the People import.

Payment history from RealGreen (amount, date, method, status) migrates as a custom Payment_Record object linked to the parent Work_Order. Payment tokens and ACH/credit card references are NOT migrated — those live in WorkWave Payments' token vault and cannot be exported. The payment record preserves financial history for reporting; the actual payment method must be re-established with the new payment processor in Twenty.

RealGreen's territory labels (geographic service areas, routing zones) are stored as a text or select custom field on the Work_Order object. If the team uses a structured list of territories, FlitStack creates a select field with the same options so filtering and reporting work in Twenty's kanban and table views.

Notes attached to RealGreen customers, companies, or work orders migrate as Twenty Notes linked to the corresponding People, Companies, or Work_Order record. Attachments (e.g., signed forms, property diagrams) are downloaded from RealGreen's file storage and re-uploaded to Twenty's file attachment on the related record. File size limits on Twenty's cloud tier apply to individual uploads.

Follow-up tasks and to-dos created in RealGreen (e.g., call customer, schedule re-inspection) migrate as Twenty Tasks linked to the relevant People or Work_Order record. Task status (completed, pending, cancelled) maps to Twenty's status field. Overdue timestamps are preserved in a custom Original_Due_Date__c field for reporting continuity.

RealGreen's dynamic routing engine generates route IDs and crew assignments that have no native equivalent in Twenty's CRM model. These are preserved as a text custom field (Route_Reference__c) on each Work_Order for historical reference. Route optimization logic must be rebuilt using Twenty's workflow builder or an external routing tool — FlitStack exports the RealGreen route schema as a rebuild reference.

RealGreen's Customer Assistant Portal access flag indicates whether a customer has self-service login credentials. Twenty has no native customer portal concept; this is preserved as a boolean custom field on the People record for reference. The customer-facing self-service experience must be designed and configured separately in Twenty.

RealGreen uses flag codes to categorize customers by status (e.g., priority, do-not-service, pre-pay). These are imported as a text custom field (RG_Flag_Code__c) on the People record. If the team uses a defined set of flag values, a select field with those options is created so filtering and automation triggers in Twenty work the same way.