Use Cases
Last modified: 10 February 2025The list of possible integration and migration scenarios is endless. Below are a few examples of how you might put Ziggy to use.
Integrations
Update CRM when another system modifies data
A common use-case is when one or more of your systems change data that requires an update in your CRM platform. There are various solutions, depending on what your billing system supports.
You have a billing system and someone adds or modifies a billing item. This change should add or modify an entry in your CRM to reflect this activity.
When the data is received in a Ziggy Flow, you can transform, validate and cleanse the data before updating your CRM.
Click on the tabs to see possible solutions for getting the change data into Ziggy.
The easiest and preferred approach is to create a webhook in your billing system that makes an API call to a Ziggy Flow with the change data in the payload.
Changes are written to a file in any format and stored on an SFTP server. Ziggy can schedule Flow to read from that server as often as you like. This approach might require a developer to create the file if it cannot be created automatically.
Older systems might require you to work with the billing system database directly. You could have a developer create SFTP files, send data using a database trigger or a queue table. You could also ask Ziggy to poll for changes in the database.
Dashboard, Reporting and BI data preparation
You have various siloed systems, and you want to provide a data warehouse or database that you can use as unified data store for your reporting tools.
Update a data warehouse or database with selected data whenever a record is modified in your CRM, Billing, ERP (etc.) systems
You can create a Flow for each of your source systems that receives data (Webhook, SFTP etc.) whenever a data item is changed in the source system. The Flow can then transform the data as required and write to the data warehouse or database.
Depending on your use-case, you could also read larger quantities of data on a) a Ziggy scheduled "pull" basis or b) a source platform "push basis. Data transformations can be applied as required.
Forms processing
You probably have forms in many places in your websites and applications. Ziggy can help data coming from a single form deposit data in multiple platforms.
A product order form should pass data to Stripe, validate payment and, once payment has been received, update your CRM and billing systems.
Your website calls a Ziggy Flow using an API call. Ziggy calls the Stripe API with the relevant parts of the order data and creates a payment intent
When Stripe has finished processing the payment, a Stripe webhook calls a Ziggy flow, which can then update whichever systems require updating with the order information, for example your CRM and billing systems
Data Collection
You might want to collect data from surveys or other forms based approaches. Ziggy makes it easy to get the data from your various data collection sources into databases, data warehouses or any other data format ready for analysis or processing.
Migrations
Migrations are closely related to integrations. From a Ziggy perspective, you use the same toolset but require a different strategy in your Flows.
The main differences from integrations are
You will often start a migration from the Ziggy UI unlike integrations, which are usually triggered by an API call from another system.
You are often dealing with very large volumes of data. This means you have to consider "Batching" or "Queueing", both of which are handle by Ziggy.
You will need to perform a lot of data transformations to map from your source platform's data structures to your target platform.
You will often not want to migrate your data directly from the source into the target. It is often better to load the data into the Ziggy data store or an external database first. This allows you to perform all you quality control checks and experimentation before sending data, that otherwise might be insufficiently tested, into the target platform.
Salesforce to Hubspot migration
Migrating this data can be very challenging. For each data type (Company, Contact, Deal, Custom Object etc.), you will need to perform data transformation and cleansing. Operations such as record associations and file attachments also need to be factored in.
The complexities of a large scale data migration should not be underestimated. Ziggy can significantly reduce the time required and help you develop and test your migration in a much more controlled fashion.
Migrate all standard and custom data from Salesforce, performing the following operations.
Import data from each object type into a database, including activities such as Todos, Tasks, Calls, Appointments etc.
Perform data transformations from the Salesforce to the Hubspot format.
Store the source raw data and the transformed target data as a part of this process
Allow imported data to be searched for and viewed.
Transform the Salesforce record owner/user into Hubspot owner/users
Store all associations between the records
Store all file attachments
Use the Salesforce API to extract the data and write into the Ziggy Data Store.
Use Ziggy structures and mapping to transform the data into the Hubspot data formats
Use the Ziggy Data Browser to view the source and target data and check for transformation accuracy.
Run a Flow to get the association data and store this in the Ziggy Data Store
Allow the associations between objects to be visualised for testing purposes.
Import all Hubspot properties into the Memory store for data validation checks in the next step.
Check the transformed data against the Hubspot properties to ensure the export will succeed
Upon request, run the export process for each object type.
Generate the association in Hubspot
CSV to CRM
In many cases, a CSV import is preferred. It is generally less powerful than the API -> API approach, but it is often the only way the data can be provided.
The requirement and solution talks about Hubspot but the process is the same for any target CRM platform.
Company, Contact and Deal and Line Item data is provided in four CSV files. The associations between these are made using ID fields.
Import data from each CSV file type into the Ziggy Data Store.
Perform data transformations from the Salesforce to the Hubspot format.
Store the source raw data and the transformed target data as a part of this process
Allow imported data to be searched for and viewed.
Transform the Salesforce record owner/user into Hubspot owner/users
Store all associations between the records
Store all file attachments
Use Ziggy structures and mapping to transform the CSV data into the Hubspot data formats
Get the associations between the respective CSV files and store in the Ziggy Data Store
Use the Ziggy Data Browser to view the source and target data and check for transformation accuracy.
Allow the associations between objects to be visualised for testing purposes.
Import all Hubspot properties into the Memory store for data validation checks in the next step.
Check the transformed data against the Hubspot properties to ensure the export will succeed
Upon request, run the export process for each object type.
Generate the association in Hubspot