What is your primary use case for SnapLogic Intelligent Integration Platform (IIP)?

My main use case for SnapLogic is for different projects involving data migrations. We need to migrate data from our old SQL database to SnapLogic. I am mainly using it for this purpose and am currently learning the platform. Data migration is the primary project we are using SnapLogic for at this time.

My main use case for SnapLogic is data ingestion. We have lots of data, but the main one is connecting out to APIs and SQL databases, bringing them into all the various system sources that we have within the business. A specific example of a process or workflow I run with SnapLogic for data ingestion is that we recently built a data lakehouse within Databricks. We use SnapLogic to connect to all of the system data sources, and with a little bit of logic, we create Parquet files for Databricks ingestion.

My main use case for SnapLogic is to automate SFTP pickups and banking integrations, and I also use it for data formatting, changing CSVs into different types of files, filling out data, and completely changing it for all sorts of data work. A specific example of a workflow I automate with SnapLogic is when we receive a file from a bank about different transactions in US dollars and in Philippine currency as a text file in an old bank style format that needs to be converted into an Excel sheet for one of our other platforms. In this example, I first transform the file and remove any unnecessary data. Since the file is a text file without proper spreadsheet formatting and no real columns, I must ensure that I am reading and formatting the file correctly into columns and rows so that it displays properly for our other platforms. In addition to my main use cases with SnapLogic, I also use it in a couple of places to work with our internal APIs as a company, where clients want to provide us data, whether it may be a list of customers or a list of accounts that they work with, and they want to give it to us in a CSV format and do not feel comfortable using an API and calling it.

My main use case for SnapLogic involves all the ETL applications where I need to get data from sources and then perform transformations and either send it to downstream applications within our firm or to any external vendors that need specific data sets. For one of those ETL processes, I can give a specific example where some applications need data related to people and some of their transactions, which we hold in different applications. For people data, we use SnapLogic to connect to Workday and get their information such as first name, surname, preferred surname, and HR number, while their transactions, which are the things they actually work on, do not exist in Workday. These transactions are stored in a different application called 3E. In the same integration, SnapLogic gets people data from Workday and financial data from 3E, which is related to different users, and then we map them together by using joins and send all the user-related data along with their related financial transactions. We group them together, and each of the user data will be sent to an external vendor. This main use case is our primary use case in most of the integrations.

My main use case for SnapLogic is creating pipelines for data migration projects. A specific example of a pipeline I have built for a data migration project is when we have our old product in a different technology that we are moving to the new product. For that, we are moving the data from SQL to the Next Gen SQL database. We are creating pipelines through which we are moving the data from the old product to the new product. As of now, we are only using SnapLogic for data migration projects.

My main use case for SnapLogic is performing data migration. A specific example of a data migration project I've done with SnapLogic involves dealing with the EHR system, where we are using SnapLogic to migrate our environments, and we have the migration projects as well. Along with SSIS, we are working with SnapLogic, and we basically deal with health and safety.

My main use case for SnapLogic is for data migrations, where I am building pipelines. A specific example of a data migration project I handled with SnapLogic is moving our legacy product, EHSS Pria, to the new one by building pipelines with the base being the SQL database.

For data migrations, we are building pipelines with SnapLogic. We have our legacy product, EHSS Pria, and from there we move to the new one by building pipelines with the base being the SQL database, which we handle with SnapLogic. I have provided details about my main use case and ways I am using SnapLogic.

My main use case for SnapLogic is integrating multiple systems. For integrating those systems, I am using SnapLogic to integrate the whole order-to-cash flow where the quote originates or an opportunity originates from Salesforce, goes through a whole lifecycle with SAP and multiple internal systems, and comes back to Salesforce as an order for revenue generation. In addition to integrating the whole order-to-cash flow, I am using SnapLogic to connect multiple systems including multiple APIs, DBs, MySQL DBs, Cloud Spanner DBs, GCP, Pub/Sub, Vertex AI, and APIs.

SnapLogic is used within my team for scheduled integrations of software, ETL loads, batch integrations, and real-time integrations between one of the main systems, Salesforce, and our more traditional SQL databases and Oracle Fusion ERP platform. We connect to mainly structured JSON data or semi-structured data within SnapLogic.

My main use case for SnapLogic is dragging and dropping files from one SFTP to another SFTP. A specific example of a workflow I set up using SnapLogic is picking up files from our SFTP which our system creates and drops there, then moving them across to our reconciliation team, a third party that does our reconciliation on an automated schedule.

The main use case for using SnapLogic is to integrate external systems to Syndigo. For example, we have XML files that need to be converted into our Syndigo format to create entities in the Syndigo system.

My main use case for SnapLogic is data migration from databases to new systems using APIs or direct database-to-database transfers, as well as generating reports for various purposes. A specific example of a migration I completed using SnapLogic involved moving data from SQL Server to a NextGen system that Ideagen currently owns. This migration was particularly interesting because it had many dependencies from within the incident module. Every time data was posted, it used a unique identifier that needed to be saved back into the database and then used again, which made the pipeline design quite complex.

I have been using SnapLogic for one and a half years on various multiple projects from the perspective of data migration and ingestions. My main use case for SnapLogic is migrating some legacy product data to our newest products. A specific example of a migration project I handled with SnapLogic involved our legacy product, which has multiple modules within it. Regarding my main use case and other ways I use SnapLogic, we import the data as part of the ingestion process. We edit the data into an Excel tool in an Excel sheet and, using SnapLogic, read the data from the Excel sheet and load it into our newest product.

My main use case for SnapLogic is importing data to my CRM. I use SnapLogic by taking data from the JustGiving platform through an import file dropped into a specific location and loading it into my CRM.

My main use case for SnapLogic is integration with other systems, and I also use SnapLogic to replace a lot of our older systems that require integration. A specific integration I set up with SnapLogic that made a significant difference for my team is called SGM, which is a Stanford Group Manager. It was originally written in Java and worked on a very old server, so instead of migrating the code and the technology to a new server, I redeveloped it using SnapLogic. Once I redeveloped it using SnapLogic, the integration part lagged a bit, so I still had to use some Java, especially for the integration with Active Directory. Even though SnapLogic provided resources and snaps for that, it was still inefficient. Additionally, I had to integrate new harvesters, which are the logic side where they post events and process them. As SnapLogic matured, I rewrote part of that to spawn duplicate processes to execute and run a lot of the back-end integration, really cutting down on time, and as SnapLogic continues improving and I learn more about it, I continue to upgrade our current systems to make them more efficient and outperform a lot of our old systems. One other benefit about my main use case with SnapLogic is the harvesters, which went through about four or five revisions before I created a standard template snap where I could use a property file to achieve the same information instead of repeating the pipelines or projects. Therefore, when someone does a request and they need this simple integration, I retrieve some information from a get and then post the information to a downstream system that could have multiple authentications, which I can now do all within a property file. This enables me to spin up a new harvester in SnapLogic within half a day, saving a lot of time.

I use SnapLogic for e-commerce, marketing, data analytics purposes, airline, banking, and integrating for ETL and ELT concepts. A specific example of how I use SnapLogic for these purposes is an ERP system such as SAP, Salesforce, or JD Edwards, where we collect the data and perform the transformation as per the requirement, then parse or format them as required by the target source, and then send the data to the target systems. Recently, for an integration for financial analytics, we needed to collect raw data from more than seven to eight ERP systems and then load them into a data lake target system. In that case, we needed to build the transformation and mapping parts for each ERP, then load into the data lake using the same structure or pipeline without rework, which was quite helpful in that integration.

My main use case for SnapLogic involves replacing old ETL functions, improving data flow, and enhancing efficiencies, business processes, and data quality across the enterprise. A specific example of how I am using SnapLogic to improve a particular business process or data flow is that we have been able to go directly to subject matter experts and, through complete requirements-based discovery, rebuild, replace, and improve entire business functions very simply, quickly, and in ways that we were not previously able to do. Some functions that had been static and out of date for three, four, five years have been able to be turned around completely within a matter of weeks. The entire previous ETL architecture has been replaced within 12 months from when we started. It is very easy to adapt to SnapLogic. It is very user-friendly. People who have not used the product with previous experience of any kind have been able to pick up and deliver most of this internally within the last year. While we have had a lot of external help from SnapLogic themselves, it has been a revelation compared to older, legacy ETL functions.

SnapLogic is used for system integration, similar to SSIS, and also for more complex integrations such as integrating our HR system to various partner systems, both on-premises and cloud-based. We now have a single publisher from our HR system that is triggered and managed by SnapLogic, which delivers it out to various partner systems. This allows us to support benefits for our employees, employee tracking, and employee reporting in a secure and safe way. SnapLogic is also used in conjunction with our event bridge for event processing, functioning almost as an adapter. It allows us to take messages off our event bridge and integrate with systems that would not naturally talk in an event-based way.

SnapLogic is used in three different areas within our organization: primarily data ingestion, reverse ETL, and the most critical aspect is building APIs. We build APIs in SnapLogic that get exposed to both third parties and internally. A specific example of how I use SnapLogic for building APIs is in our CPQ integration, where a sales representative can make a quote by using Salesforce to call the API we created, connecting to our internal systems for customer and product information as well as Zuora to create a preview order, including calculations such as taxes. Once the quote is complete, the salesperson makes another call when the order gets created, pushing that order into our provisioning system and Zuora for billing, all managed with another API. Additionally, once the order is fulfilled in Zuora, we receive an event through a real-time API that pushes data back to Salesforce. In addition to the CPQ example, we also create or transform data in Databricks using SnapLogic to send data back to our various systems. One of the more complex use cases involves sending emails to Iterable, as the data in one system is stored in a very structured way, while Iterable uses a more complex JSON structure, consuming the most memory and resources in our SnapLogic nodes.

Our main use case for SnapLogic is the integration of student data, some finance data, and some internal Stanford data processes. A specific example of how I use SnapLogic for integrating student or finance data is when new staff, students, or faculty join Stanford; they have to be added to different workgroups or their email has to be set up, so many processes are done via SnapLogic integration. On the finance side, it involves processing data related to the Office of Development, where some gift processing happens. Multiple teams at Stanford, including the School of Business, use SnapLogic for tasks such as booking meeting rooms. We use SnapLogic for various integration purposes, including integration from Salesforce to Oracle, from flat files to Oracle, and integration from FileMaker to Oracle, among others. Although many more integrations are running as pipelines, these are a few I can recall as an infrastructure team member.

SnapLogic serves as our primary ETL tool to replace legacy ETL tools and move data through our systems. Processing events data is our best example, where event information comes from third-party platforms that we need to incorporate into our internal data ecosystem.

My main use case for SnapLogic is automating data ingestion. I am using SnapLogic to automate data ingestion by collecting data from sources such as AWS or SAP and then enriching data and loading it into a data cloud. That is the main way I'm using SnapLogic right now.

My main use case for SnapLogic is to load data into our CRM, which involves normal ETL and extensive data cleaning before putting it into the CRM. A specific example of a project where I used SnapLogic for ETL and data cleaning is when we receive data from the bank and use that spreadsheet to find a contact in the CRM and then create income records on the spreadsheet and push it into the CRM. I use SnapLogic to execute the process, and it is all working well now, following business logic, and the process is very quick and easy. These days we are trying to use SnapLogic to integrate it into an API to call those data and push it into the CRM instead of picking up files, and I think that is the next stage we are going into, but as it develops, we will see what more things we can use SnapLogic for.

My main use case for SnapLogic involves migrating data from legacy to the latest product. We are migrating heritage products to the latest products using SnapLogic. One specific example of how I used SnapLogic in these migrations is that we take data from the source using SQL views, perform some transformations in SnapLogic, and once transformations are completed, we move data into an interim database, and from there we push that data to the target system using APIs.

My main use case for SnapLogic is data integration. A quick specific example of how I use SnapLogic for data integration is connecting to external sources such as APIs and SFTPs to obtain supplier product data as well as public data from things such as gov.uk and bringing it into a centralized location within the business. I found the process of connecting to those external sources with SnapLogic quite difficult at first, as there was quite a steep learning curve involved with SnapLogic. However, once the GPT had been activated, it made the learning curve significantly smaller, and therefore the ability to connect to those external sources was a lot easier.

The main use case for SnapLogic is data integration between different applications and automating data workflows. We use it when we have a different set of products where we have to migrate data from one product to another product, such as from our legacy product to the new product. For example, we had one data migration project where our Priya customers had to be migrated to the new product, which is the Devonway application. We used SnapLogic to migrate the data from Priya to Devonway.

My main use case for SnapLogic is developing pipelines to transfer data from a source into our Dynamic CRM. We are thinking about using APIs and more with AI within our pipelines, and hopefully, in the future, we want to develop pipelines to write into our data warehouse once we have that implemented.

My main use case for SnapLogic is that we primarily use it for data transformation, ETL pipelines, file generation, and sending extract files to our external vendors. I can give you a specific example of how we use SnapLogic for one of those tasks. Every day we receive claim files from our primary vendor and we load those using SnapLogic and transform the data accordingly to match our database schema. After the files have been loaded, we send out many different extracts to different vendors depending on their needs, and all those extracts go through SnapLogic. I have more to add about my main use case and how SnapLogic fits into my workflow. We also use SnapLogic scheduled tasks for many of our processes. Some of those are daily and some of those are monthly, but we enjoy using SnapLogic to schedule those tasks out accordingly. It has helped significantly with organizing those different scheduled tasks and keeping us on track with different deliverables for several vendors that we have.

I have been working in the integration space for more than 10 years, starting my career with SnapLogic, which is a good iPaaS tool for integration. Even taking a look at the market caps, SnapLogic is doing very well. In any organization when an integration requirement comes, whether it is an on-premises to cloud connect, or whether it is any kind of migration or grabbing data from SaaS tools such as Workday, NetSuite or Salesforce, SnapLogic is a best fit in the market. It has lots of pre-built connectors called Snap-packs, which come pre-built with SnapLogic licenses, so you can make use of all those together. This is the main use case that motivates us to use SnapLogic. There are so many features, and from the user perspective, it is very user-friendly. It is a low-code, no-code platform that can be used for any integration use cases. I recently completed a Workday migration project. Hitachi wanted a Workday system to be a single source of truth across all Hitachi organization and sub-organization. There we got a use case to integrate the Workday system with all the downstream systems, whether it is for HDS or Hitachi Digital Services, Hitachi Vantara or GlobalLogic. SnapLogic was used in that case. There are so many inbound and outbound integrations, and we integrated two or three kinds of authentication to pull out data from Workday and also to send out any kind of inbound data to Workday. This was our main use case and it was a very big project in Hitachi Digital, the Phoenix project, and all those implementations happened on SnapLogic. I can also mention that we recently built a professional service automation with the help of SnapLogic, which is the integration between Salesforce and Oracle ERP system, Oracle HCM system, which is used for the HR system in GlobalLogic. Lots of insourced data are brought to the Salesforce platform so that they can tag the right resource to the right project and they can also check the utilization. Professional service automation is a kind of automation that will tag the right people at the right skill set on the right project. For all those to achieve, we used SnapLogic to integrate between Salesforce and the Oracle system.

SnapLogic is my primary automation and integration platform that I use daily. A specific example of how I use SnapLogic day-to-day involves a number of different syncs, such as having CRM data from Salesforce syncing over to our Zendesk instance for our support teams and similarly, Salesforce going to Marketo for our marketing teams. We have various third-party platforms that we're sending logs to, such as Elastic and Zilla for security and governance, and we have various data transformations, gathering and aggregating data from various systems and then spitting that out to dashboards and Google Sheets or Tableau in various different places. We have been focusing on AI use cases with SnapLogic lately, specifically on different sales-focused ones like a daily task looking at different Salesforce reports and trying to gather various context from Salesforce and maybe some other different systems to create a full context picture using an LLM to aggregate that, put together a report and send that on to some of our reps for them to action on.

I have been using SnapLogic for 12 years and it continues to run effectively. SnapLogic serves as an integration platform in our IT application team to exchange data from one application to other applications and perform the transformations required if they are ever needed. We have various types of sources. It can be SaaS applications and on-premise applications. Based upon the business requirements and other factors, we extract data from the various sources, either from the specific Snap Packs or through the REST APIs. Some applications generate files and place them on file servers. We use all methodologies, including SnapLogic Snap Packs, direct connectivity with those sources, or file-based integrations. We also use SnapLogic as an API. With the help of that, we extract all the data from the sources. We perform the business transformations wherever required as per the target system needs or the business requirement needs. Then we connect the target applications, either through dedicated Snap Packs such as Workday, Salesforce, Oracle ERP, SQL Server, any third-party applications, or SaaS applications if we have the Snap Pack. Otherwise, we use SOAP services, REST methods, or API-based integrations to connect the target applications. We have ample and a variety of use cases. It can be batch-to-batch jobs, integrations, scheduled integrations, API-based integrations, and all these things. Currently, we are assessing SnapLogic API and features so that we can deploy all our existing APIs and build new APIs while having the complete API lifecycle management within our organization. Many of the use cases are API-based, and we need to be more secure about our APIs.

We are building the Finance Operation Warehouse for organizations with SnapLogic Intelligent Integration Platform (IIP), bringing data from heterogeneous sources and converting it for consumption by some other cloud platform or ERP platform. Once accounting is done, we are pulling it back from the ERP via API calls and putting it into a Snowflake layer, which is the typical use case where we leveraged SnapLogic Intelligent Integration Platform (IIP).