Migrate from FotoNotes to Pipedrive

FotoNotes container hierarchy has no native Pipedrive equivalent — relationships split across objects

FotoNotes organizes properties and projects in a Container/Containee hierarchy where Work Orders nest inside parent Containers. Pipedrive has no native hierarchical container object — the data model is flat. We split the hierarchy into two Pipedrive object types: each FotoNotes Container becomes an Organization, and child Containers are separate Organizations linked via the Organization parent_id field. Work Orders under each Container become Deals linked to their parent Organization via org_id. The parent-child relationships are preserved in custom fields for post-migration verification. Manual review of the consolidated hierarchy in Pipedrive is required before go-live to confirm that all nesting is correctly reflected.

FotoNotes role-based permission model has no Pipedrive equivalent — access control must be rebuilt

FotoNotes defines nine named roles (Portal Admin, Manager, User, Field User, Customer, Vendor Admin, Vendor Field User, and two Vendor Admin variants) that control visibility of work orders, photos, and documents per property. Pipedrive's role model uses visibility groups and permission sets scoped to CRM data — it has no concept of field-service access tiers, vendor-only portals, or customer view-only access. We migrate user records and preserve role assignments as custom fields on each Person record, but Pipedrive's sharing model must be rebuilt by your admin. Vendor and customer-facing portal access has no equivalent in Pipedrive's standard interface — this use case requires a separate customer portal add-on or custom development.

Pipedrive 25 MB per-file limit catches large FotoNotes photos and documents at migration time

FotoNotes stores photos and documents attached to work orders and containers without a per-file size cap — property inspection photos can routinely exceed 25 MB, especially for high-resolution construction documentation. Pipedrive enforces a hard 25 MB limit on file attachments via its API and UI. Files that exceed this limit fail during migration and are flagged for manual extraction. We pre-scan FotoNotes attachments for size before the migration run and generate a pre-flagged report of oversized files. Teams typically extract these to a shared drive or cloud storage and re-upload manually to Pipedrive with links recorded in the Deal or Organization note. This step adds manual effort not present in FotoNotes-native workflows.

Migration must sequence Organizations before Deals due to Pipedrive foreign-key dependency

Pipedrive requires an Organization to exist before a Deal can be linked to it via the org_id field. If a Work Order is migrated before its parent Container record, the Deal lands with a null org_id and must be corrected in a post-migration cleanup pass. We sequence the migration in explicit dependency order: Organizations first (FotoNotes Containers and Properties), then People (Field Users, Vendors, Customers), then Deals (Work Orders) with their org_id resolved from the already-migrated Organization records. The FotoNotes API export is ordered to produce this sequence automatically. Any orphan Deals created by out-of-order migration are flagged in the audit log and corrected before the delta window opens.

Work Order status and stage are not Pipedrive Deal Stages — semantic mapping requires custom fields

FotoNotes Work Orders carry a status field with values such as Open, In Progress, Completed, and Flagged — these drive field operations workflows and completion reporting. Pipedrive Deal Stages are tied to sales pipelines and drive probability, forecast category, and CRM automation triggers — they are not interchangeable with field-service status. If FotoNotes work order statuses are mapped directly to Pipedrive Deal Stages, the stage probability and forecast implications will misrepresent the actual work order lifecycle. We map FotoNotes status to a custom field (Work_Order_Status__c) on the Deal record and leave Pipedrive Deal Stage set to a neutral 'Work Order' pipeline stage. The status history migrates as a custom datetime field showing when each status transition occurred.