Vinay K.

I implemented a similar approach to Shiva, and I believe this is one of my best design approaches, focusing on execution efficiency and Workato optimization. As part of the Salesforce Opportunity Sync migration from MuleSoft to Workato, I leveraged the Salesforce Bulk API to process 367K+ records in under 7 minutes as part of a full-load daily sync using 1 business task. This was a critical integration for the customer, and we successfully migrated and executed it smoothly in Workato. Handling this volume of data within such a short execution window demonstrates the value of choosing the right architecture and optimizing bulk-processing capabilities. The customer was happy with the execution speed and overall performance, especially given the critical nature of this integration. It was a great example of delivering a scalable, efficient, and reliable solution through the MuleSoft-to-Workato migration. Proud to have contributed to this successful migration, with a strong focus on performance, scalability, and reliability.

looks like it is working now

yes even in our client workspace we are facing this outage issue

Hi steve.waldron, It is working for us, please try to re-login again and see if it works for you

Standard PostgreSQL connector actions such as Insert, Update, and Upsert are executed and committed individually. Once an operation is committed, Workato does not provide a native rollback option to undo that previously completed action. Maybe you would need to implement compensating actions, such as deleting a previously inserted record if a subsequent operation fails. Let's see if anyone else responds to this with more information

You can use the Run custom SQL action and handle the transaction at the PostgreSQL level using BEGIN, COMMIT, and ROLLBACK, or encapsulate multiple database operations in a stored procedure.

Hi Priyanka B., as far as I have seen, the Workato PostgreSQL connector does not provide transaction handling similar to webMethods Local Transaction or XA Transaction.

it will work, try to create new proper csv and check once again

Hi sonal, Workato does not provide a native Dead Letter Queue (DLQ) like MuleSoft or messaging platforms. To understand the retry and DLQ implementation, we should review the recipe's Handle Errors configuration, connector-level retry settings (if applicable), and the overall error-handling design. We should also verify whether failed payloads are persisted in a Data Table, database, S3, or another storage mechanism for replay, as this typically serves as the application's DLQ. Additionally, reviewing failed job logs in the Jobs section will help identify the current retry behavior and failure handling.