What is your primary use case for SnapLogic?

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.

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.

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.

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.

Our main use case for SnapLogic is building and managing data integration pipelines between different systems, especially for automating API-based workflows. It helps streamline data movement, transformation, and orchestration without heavy manual intervention. For example, in our day-to-day work, we use SnapLogic to integrate data between internal systems and external services. The typical pipeline involves fetching data from an API, transforming it based on the business requirements, and loading it into another system or database. This automation reduces manual effort, ensures consistency, and allows us to handle updates in near real-time. In addition to core data integration, we use SnapLogic for workflow orchestration and monitoring. It helps manage end-to-end data flows with better visibility, error handling, and retries. We also leverage its reusable pipelines and connectors to standardize integration across teams. This reduces development time and ensures consistency, especially when working with multiple APIs and systems. Overall, it plays a key role in making our process more efficient.

I connect system to system, and sometimes I do applications to applications as well. When required, I build some APIs in SnapLogic and expose them to customers. From a general automation perspective, when a business wants to automate a particular use case, it can be anything. For example, tickets are getting created in ServiceNow where I need to automate the ticket creation with the information I receive back to Jira or something similar. I connect with systems such as ServiceNow and Jira and automatically create an automation workflow that connects these two systems to make the process automated, which saves manual effort. I work on many use cases across different domains, such as HR, sales, and many other domains. I use SnapLogic in the regular way, as it needs to be used.

My main use case for SnapLogic is integration and automation, where it connects different systems, applications, databases, and files so data can move automatically between them. A company's sales team uses Salesforce to create customers while the finance team uses SAP for billing and the support team uses a ticketing system. Previously, whenever a new customer was created, sales emailed finance, finance manually created the customer in SAP, and support manually set up the account. Errors and delays were common. SnapLogic helped by building an automated pipeline where the trigger was when a new customer was created in Salesforce. SnapLogic automatically validates customer data, creates the customer in SAP, creates a support account, sends confirmation emails to stakeholders, and logs everything for audit. This resulted in reduced onboarding time from one to two days to a few minutes, eliminated manual data entry errors, improved customer experience, and saved operational effort. Another example of SnapLogic usage in our organization is automating daily sales reporting instead of manually downloading and merging data from a POS system. The pipeline automatically extracts, transforms, and distributes reports every morning.

My main use case for SnapLogic is to build integrations between two different applications or systems, mostly to facilitate the integrations part. I can give you an example of an integration project I have built using SnapLogic. I built one of the more complex integrations, which was near real-time customer data synchronization between the Salesforce on-premise ERP system using SnapLogic. Their goal was to make sure both systems stay aligned on customer records, orders, and their status updates without any human intervention. So, the main goal is to make it all automatic with SnapLogic process. I designed a triggered pipeline using a Salesforce listener tap that captures all the record changes, ensuring no human intervention is needed. This data flows through validations and transformation Snaps, where I standardize the formats, handle a few operations, and ensure full consistency with the data. I also implemented a reusable error handling sub-pipeline that logs the failures in monitoring databases and sends alerts through email or channel notifications. For the ERP side, I exposed SOAP services, configured the SOAP execute Snaps with dynamic requests, and generated the payload as well. I ensured performance optimization issues were addressed as the volume increased by batching requests and parallelizing the process. This integration is now fully automated and monitored, requiring no human intervention. This is one of the integration projects among many I have worked on with SnapLogic. I have also handled various integration use cases with SnapLogic. I have built REST API pipelines used to expose backend security to external applications, utilizing API tasks, API policies, and pipeline parameters. I have focused on batch ETL data pipelines for migrating large datasets from databases, like Snowflake to other cases, using bulk Snaps throughout. Additionally, I have worked on event-driven integrations using ultra pipelines for low latencies. I have connected applications, integrating CRM to ERP and ERP to CRM, where I handled mapping, transformations, validations, and reconciliation reporting. Another use case is for file processing automation, particularly with automated ingestion of CSV, XML, and JSON files, where I parsed and validated the file structures before loading into databases and generating reports and success/error messages. Lastly, for error handling and monitoring frameworks, I built and logged failures to database log services, created alerts via email or Slack, and stored failed payloads for retrievability, ensuring data quality and transformation pipelines with standardized formats. These represent some of the many use cases I have worked on.

My main use case for SnapLogic is migrations from Boomi and other SQL databases to SnapLogic. Regarding the SQL database, I'm not going to disclose the customer name, but I can give you some highlights. It was financial data for a Fintech organization. They wanted to move from their PNL and GL data. All these migrations and the benefits data, which they have to send to the third-party system, moved from another iPaaS system to SnapLogic because of delays and latency, which was the biggest issue for them. So, we built up plenty of data lakes and migrated the data back to SnapLogic. Similarly, for the SQL database, it wasn't only the latency, but they were also facing issues where people were unnecessarily writing a lot of triggers. They didn't think that was the correct way because there was no alignment or streamlining in terms of process design or the reusable storage of technical resources. They wanted to identify and streamline the entire process, as well as build some kind of reusable process. I have also found that SnapLogic, or perhaps Boomi or MuleSoft, whatever the customer is going to choose, has some kind of edge in terms of processing data quickly and with a reduced amount of latency. I don't know what changes they are going to do with the help of agent AI, all the pipelines, and DataBricks, and all these things, and how they are going to put the data in perspective within the application. That is the use case I can tell you.

Our main use case for SnapLogic is building integration pipelines across SaaS applications, databases, and internal systems to automate the data flows. A specific example of how we have used SnapLogic to automate a particular data flow is leveraging its drag-and-drop pipeline builder and pre-built snaps to build complex integrations in a simplified manner.

Regarding automation, there were multiple business requirements to automate processes, such as sales processes and finance data. They wanted to integrate with different systems and achieve accurate results with the reflection of accurate data into correct databases. In that way, we can use SnapLogic to integrate and load; it is ETL, extract, load, and transform with different databases. With those databases, it will be really helpful to use SnapLogic, which will serve as the middleware tool to make it easy to transform data. For deployment, we were raising requests to another team. They were creating solutions to make it happen with the help of Postman; we were adding details, and using the Postman tool, they were integrating or deploying in another environment.

I mainly use it for data integration and some API tasks.

I utilize SnapLogic for data migration and data integration projects. I use it mainly as a middleware tool, working with a lot of SAP data. By transferring SAP data into more cost-effective databases, I can run analytics without the high cost associated with SAP provider analytics.

In our company, we used the solution to build a SnapLogic pipeline in a non-production environment. Presently, our company is releasing it to the production environment. We have used SnapLogic in our organization for integrations. An EDI pipeline is built first, and then SnapLogic is utilized to convert EDI format to JSON and vice versa. Leveraging the internal systems in our company we are connecting to the SnapLogic API and sending the data, and then the converted files are obtained from SnapLogic.

I work as a solution architect, mainly focusing on integrating new software entities. Due to a client's needs to evaluate products, SnapLogic was considered, and we conducted some Proof of Concepts and suggested its use. So, our end customer is one of the medical equipment companies. They were looking for an integration solution, so we analyzed their requirements and determined what would best suit their business.

It's similar to other tools like Boomi. But, it's a smaller player, not as widely adopted. SnapLogic may be easier to use, with less coding, but I think that more comprehensive solutions will handle a wider range of tasks. I found it difficult to achieve what I needed with SnapLogic.

SnapLogic and Pentaho are tools I use collaboratively for data integration. I have good experience with Pentaho and SnapLogic for data migration from one database to another database. The main use cases of the tool are for data integration and migration from databases. In most of the use cases, my company uses SnapLogic for the migration of flat files to S3 and other databases. If my company gets flat files, like CSV, PostgreSQL, and XML files, from our clients, what we do is based on some of the business logic and the implementation they send to us. For my company to apply some business logic and implement it on top of the flat files, we will transfer the file using transform logic, after which we will migrate the data into the database, like Oracle or PostgreSQL.

It's useful to move data from one environment to another one, for example, from one database to another one. I can also change data types, delete some dates, update data, and clean data, for example. So it's really useful for us.

We use SnapLogic to connect APIs for effectively transferring and integrating data across multiple systems.

I was utilizing Azure Data Lake block storage as a data lake, and I was performing numerous source extractions from various sources and transferring them to the data lake.

We are using it for ETL and application integration.

Our company is a partner and uses the solution as our main tool for client integrations. The solution works for any sized company to integrate HR, financial, and operational processes that sync data between databases for ETO transformations. The solution is effective at syncing data between different sources and targets including Snowflake and other data warehouse systems. We also use the solution to build many asynchronous and synchronous APIs that serve as the backend for systems and are easy to maintain.

I used SnapLogic for ETL purposes, particularly for automating manual activities, for example, automating validation reports, checking and generating email, etc.

When we get a requirement from the business, we'll get the mapping documents. Based on the mapping documents, we'll map the issues.

My major use case for SnapLogic is for ETL. It's for data migration purposes. For example, I've used it to move data from SAP systems, across SAP systems, or across Salesforce systems. I've also used SnapLogic to integrate data from Workday or from some downstream enterprise specific applications to Workday.

SnapLogic was used for building simple pipelines to call REST API, to get details from a file and call REST API and post those details. It was also used while working with expense solutions for finance posting and other complex solutions.

It's primarily for cloud-to-cloud application integrations. We are moving the data in Redshift that is from Amazon. Our primary use case is for data integration, data applications, and data migrations from SAP data to data in Amazon Redshift.

We primarily use the solution for integrating different applications. It's very flexible and we can use it as either a database or just a set of cloud-based applications.