Migrate from Field2Base to Pipedrive

Each Field2Base submitted form becomes a Pipedrive Activity of type 'note' attached to the corresponding Person or Deal. The note body contains the form name, submission timestamp, and key region values formatted as structured text. Original worker name preserved as Activity's subject or assignee.

Field2Base regions map to Pipedrive custom fields created via POST /personFields, /organizationFields, or /dealFields. The custom field key (a 40-character hash) is generated on the Pipedrive side first — our migration plan sequences schema creation before data writes so field keys are available for the mapping layer.

Field2Base Dropdown region values are enumerated in Pipedrive as a set of options on a custom field of type 'enum'. Each dropdown option value in Field2Base maps to an exact Pipedrive option label. If Pipedrive's enum has fewer options than Field2Base, unmapped values are preserved as a note attachment for manual resolution.

Field2Base GPS regions store latitude and longitude as separate numeric fields. We concatenate them into a Pipedrive varchar field and append a Google Maps search URL so users can click to view the location in context. The raw numeric coordinates are also stored for any downstream integration that consumes lat/long.

Photos attached to Field2Base submissions are downloaded as binary blobs via the Field2Base API, then re-uploaded to Pipedrive using POST /files with a blob payload, linked to the corresponding Person, Organization, or Deal record. Pipedrive's file size limit (25MB per file) applies; larger images are compressed before upload.

Signature images from Field2Base submissions are preserved as Pipedrive Note attachments on the relevant Deal or Person. The note body records the signer's name (from a corresponding text region) and the timestamp of the signature capture, maintaining audit trail continuity.

Field2Base workers are resolved by email address against Pipedrive's user list. If a worker email matches a Pipedrive user, the Pipedrive user_id is assigned as the record owner. Workers with no Pipedrive match are flagged pre-migration for manual user provisioning or assigned to a fallback owner on the destination.

Field2Base checkbox regions map directly to Pipedrive custom fields of type 'boolean' (stored as 0/1 in the API). This is a direct mapping where the field name in Field2Base becomes the Pipedrive custom field label and the checkbox state transfers without transformation.

Each Field2Base form template is catalogued as an Activity type in Pipedrive (e.g., 'Field Inspection', 'Work Order', 'Safety Audit') so submitted records can be filtered by form type in Pipedrive's activity list. We create the activity type via Pipedrive settings before migration runs.

Field2Base workflows — one-step review/approve chains on form submissions — have no structural equivalent in Pipedrive Automations. We export the workflow definition (trigger condition, reviewer assignment, approval step) as a JSON rebuild specification document. Your Pipedrive admin or a FlitStack consultant uses this spec to construct equivalent Pipedrive Automations with the appropriate triggers and owner-update actions.

Field2Base integrations that push form data to back-end SQL databases, ERP systems, or Zoho Desk via DIM/EDM/DUU do not migrate. We document the integration endpoints, field mappings, and trigger logic as a technical specification. These are rebuilt in Pipedrive using webhooks (outgoing HTTP POST on deal/person create/update) combined with Zapier or Make scenarios.

The original Field2Base submission timestamp is preserved as the add_time on the Pipedrive Activity record, maintaining an unbroken chronological audit trail. This alignment is essential for regulated sectors such as construction, utilities, and healthcare, where submission timing must be traceable to regulatory requirements and future compliance audits.