Migrate from Agillic to Pipedrive

Agillic Recipients with a company attribute resolve to Pipedrive Contact linked to a pre-created Organisation. Recipients with no company attribute must be evaluated: if the recipient is a known sales prospect, we create a Pipedrive Lead; if they are a marketing-only contact with no sales intent, we create a Person record with a placeholder Organisation to satisfy Pipedrive's required Organisation link on Contacts. All custom recipient properties enumerated during discovery map to Pipedrive custom fields on Person, with field type matched to Agillic's property data type (text, number, date, checkbox, dropdown). We preserve the original Agillic recipient ID in a custom field agillic_recipient_id__c for audit.

Agillic allows clients to define arbitrary custom properties on Recipients with no fixed schema. During discovery we enumerate every active recipient property via the Recipient API or Recipients Export. Each property becomes a Pipedrive custom field with a matched type: text strings become text fields, dates become date fields, multi-select options become multi-select picklists, and numeric values become number fields. This enumeration step is mandatory — any property not identified during discovery is silently excluded from migration.

Agillic Recipients with a company name attribute become Pipedrive Organisations. We resolve Organisation name from the recipient's company field, use it as the Organisation name, and deduplicate by exact match on name. Email domain extraction from recipient email addresses provides a secondary Organisation resolution strategy where company field values are inconsistent. Organisations are created before any Person import so that the Organisation-Contact lookup relationship is satisfied at the moment of Contact insert.

Agillic Global Data Tables are custom relational data structures referenced within Flows. We export table schemas and all row data, then map to Pipedrive custom objects (API name appended with __c) created before migration begins. Tables with fewer than 1,000 rows and no cross-reference dependencies may alternatively be migrated as Activity notes attached to the relevant Person or Organisation, with a note type label indicating the original table name. The customer selects the strategy during scoping based on whether downstream Flows reference these tables.

The Agillic Flow Execution ID uniquely identifies each campaign trigger instance and is appended to Activity Exports when the export setting is enabled in Agillic. We preserve this ID in a custom field agillic_flow_execution_id__c on Pipedrive Activity records. This allows matching activity records back to specific Agillic campaign runs during post-migration audit. The field has no Pipedrive-native equivalent and exists solely as a reference for reconciliation.

Agillic email activity events (send, open, click, bounce, unsubscribe) map to Pipedrive Activity records of type Task. The Agillic event type becomes the Activity subject (e.g., 'Email Sent — [Campaign Name]') and the timestamp preserves the original event time. Channel attribution (email vs SMS vs push) is stored as a custom field on the Activity because Pipedrive does not have a separate channel entity. Historical open and click data is migrated as discrete Activity records, not aggregated, to preserve the full engagement timeline.

Agillic SMS activity events map to Pipedrive Activity records with the same Task model. SMS delivery status (delivered, failed, undelivered) migrates as a custom field on the Activity record. SMS message content migrates as the Activity note body for reference. Because Pipedrive does not natively support SMS as a channel type, we create a custom picklist field activity_channel__c with value 'SMS' to preserve channel attribution across all migrated activities.

Agillic event-trigger activities (custom events fired within Flows) map to Pipedrive Event records when the original event has a start and end time. Events without a time component map to Task records. Event metadata (event name, associated Flow, trigger conditions) migrates to the Event description field and custom fields. Pipedrive Events do not support the same custom attribute depth as Agillic events, so we flatten event metadata into text fields.

Agillic Flows are campaign automation logic stored as internal execution configurations. There is no documented export endpoint to retrieve Flow logic as a portable definition. We export Flow names, associated trigger event types, and Activity history tied to Flow Execution IDs as a written inventory. The actual branching logic, conditions, and wait-step configurations must be manually recreated in Pipedrive's Workflow builder. This is a re-implementation effort, not a data migration, and we deliver the full inventory to the customer's admin team.

Agillic's Recipients Export generates a snapshot file of all recipient records and their current field values. We use this as a baseline for full-contact migrations, then reconcile against API data to identify records modified since the export timestamp. The snapshot approach is preferred for large databases (over 50,000 records) because it avoids repeated API pagination that risks hitting Agillic's undocumented rate limits. We cross-validate exported records against API-fetched records during scoping to confirm data completeness.

Agillic can export micro-audience segments to Google and Meta in real time. We capture audience definition logic, membership criteria, and sync frequency from the Agillic configuration and deliver it as a written specification for recreation in Google Ads Audience Manager or Meta Business Manager. Real-time sync does not migrate; the customer recreates the audience segments in the destination paid media platforms post-migration. We flag any active suppression list as a priority rebuild item to prevent unintended audience reactivation.