Snowflake connector 200-row cap in UiPath Integration Service: how to paginate or go async

Pravinraj Vincent, UiPath Solutions Engineer If you've moved a Snowflake query from the old activity package to the Integration Service Snowflake connector and your result suddenly stops at 200 rows, nothing is broken. That's how the connector is designed. This came up on the forum recently (someone needed about 80,000 rows, and I replied in the thread), so here's the longer version: why it happens, and two patterns that work. Why you only get 200 rows The docs for Execute Select Query Synchronously are explicit: it retrieves at most 200 records. Even if you set LIMIT to a higher number, you still get a maximum of 200. A bigger number in the SQL won't help, and there's no setting that raises the cap. What the docs recommend is to page through the data yourself. Put LIMIT and OFFSET directly in the Select Query and run it inside a Do While. The connector's technical references say the same thing: when you expect a large result set, always paginate with LIMIT and OFFSET. Pattern A: page the synchronous query Use this when each page comes back quickly. Write a query with a stable sort on a unique key, then LIMIT 200 OFFSET n: SELECT ORDER_ID, CUSTOMER_ID, AMOUNT FROM SALES.ORDERS ORDER BY ORDER_ID LIMIT 200 OFFSET 0 Generate the output schema with a literal query like the one above, with no variables in it. Generate output schema only works on a query without workflow variables. Once the schema exists, swap the 0 for your offset variable. Inside a Do While, run Execute Select Query Synchronously, append that page's records to your own collection, and add 200 to the offset. Stop when a page comes back with fewer than 200 rows. At that point you've reached the end. Two things will bite you here: Always add ORDER BY. Snowflake's own docs say that without ORDER BY, LIMIT results are non-deterministic, because query results aren't in any particular order. If you page without a sort, you can get the same row twice and miss others. Sort on a unique key. Keep the ORDER BY at the same query level as the LIMIT, since Snowflake warns that an ORDER BY in a subquery doesn't carry over to an outer LIMIT. Keep the data still while you page. Each page is a separate query. If rows get inserted or deleted between pages, the offsets shift. Run it against data that isn't changing during the extract, or against a fixed snapshot. Also watch for the connector's query restrictions. Comment patterns (--, #, /* */) are blocked anywhere in the query, even inside string values, so don't leave SQL comments in the Select Query. The synchronous activity only accepts SELECT statements. The Snowflake VARIANT data type isn't supported. Pattern B: go async for slow queries The technical references say to use Execute Any Query Asynchronously for any query that takes more than 30 seconds. That's the path when the query itself is slow, not just the result set big. Execute Any Query Asynchronously runs the query and returns a Query ID. This activity also accepts non-SELECT work like insert, update and stored procedures. Get Asynchronous Query Execution Status takes that Query ID and returns a Status. Loop with a short Delay while it's RUNNING, QUEUED, BLOCKED or RESUMING_WAREHOUSE. Continue on SUCCESS. Treat FAILED_WITH_ERROR (a problem in the query) and FAILED_WITH_INCIDENT (a server-side incident) as failures. Get Asynchronous Query Execution Results returns the rows. It has the same cap: at most 200 records per request. So page it the same way, using its own Offset and Limit properties. Its Additional conditions field takes WHERE and ORDER BY clauses, so you can put ORDER BY ORDER_ID there and keep the pages in a stable order. The docs example is COLUMN_1='value' ORDER BY COLUMN_2 DESC. To generate the output schema for Get Asynchronous Query Execution Results, use a real Query ID from Execute Any Query Asynchronously. After the schema is generated, you can replace it with a variable. If you change the query itself, regenerate the schema. Changing only variables doesn't need it. If you don't want a robot sitting in a polling loop, the connector also has an Asynchronous Query Status Changed trigger. It can start a process when an async query succeeds or hits an error. Which one to pick Situation Use Query is fast, you just need more than 200 rows Pattern A: Execute Select Query Synchronously with ORDER BY + LIMIT 200 OFFSET n in a Do While Query takes more than about 30 seconds Pattern B: Execute Any Query Asynchronously, poll status, then page the results 200 at a time You need insert, update or a stored procedure Execute Any Query Asynchronously (the synchronous activity is SELECT only) If you're on Studio Desktop, the technical references also point to the Native Search activity in Snowflake package version 5.0.1. Its docs list a default limit of 1,000 records, with LIMIT and OFFSET in the query for paging. The point still stands: you page, you don't pull everything in one call. The original forum thread, with my reply, is here: How to retrieve large datasets (~80k rows) with the new Snowflake Connector? More short UiPath fixes on the RPA Simplified YouTube channel: https://www.youtube.com/@rpasimplified Sources (claim to URL, all fetched Nov 3, 2026) Claim Source Execute Select Query Synchronously returns max 200 records even with a higher LIMIT; use LIMIT/OFFSET in the Select Query inside a Do While https://docs.uipath.com/activities/other/latest/integration-service/uipath-snowflake-snowflake-execute-select-query-synchronously Generate output schema needs a query without variables; variables can be added after same page, and https://docs.uipath.com/activities/other/latest/integration-service/uipath-snowflake-snowflake-technical-references Comment patterns blocked even inside strings; sync activity is SELECT only (INSERT/UPDATE/DELETE/MERGE/TRUNCATE blocked); VARIANT not supported Execute Select Query Synchronously page (above) Always paginate large result sets with LIMIT and OFFSET Technical references (above) Use Execute Any Query Asynchronously for queries over 30 seconds; non-SELECT commands only via the async activity Technical references (above) Async activity returns a Query ID; runs select, insert, update and stored procedures; VARIANT not supported https://docs.uipath.com/activities/other/latest/integration-service/uipath-snowflake-snowflake-execute-any-query-asynchronously- Status values SUCCESS, RUNNING, QUEUED, BLOCKED, RESUMING_WAREHOUSE, FAILED_WITH_ERROR, FAILED_WITH_INCIDENT and their meanings https://docs.uipath.com/activities/other/latest/integration-service/uipath-snowflake-snowflake-get-asynchronous-query-execution-status Get Asynchronous Query Execution Results: max 200 records per request; Offset, Limit and Additional conditions (WHERE, ORDER BY); schema from a real Query ID, then a variable; regenerate if the query changes https://docs.uipath.com/activities/other/latest/integration-service/uipath-snowflake-snowflake-get-asynchronous-query-execution-result Asynchronous Query Status Changed trigger can start a process on success or error Technical references (above) Native Search on Studio Desktop from package 5.0.1 Technical references (above) Native Search default limit 1,000 records, LIMIT/OFFSET in the query to paginate https://docs.uipath.com/activities/other/latest/integration-service/uipath-snowflake-snowflake-native-search Without ORDER BY, LIMIT results are non-deterministic; keep ORDER BY and LIMIT at the same query level https://docs.snowflake.com/en/sql-reference/constructs/limit Forum case: ~80k rows, new connector returns 200 https://forum.uipath.com/t/how-to-retrieve-large-datasets-80k-rows-with-the-new-snowflake-connector-200-row-limit-issue/5774775