👤 For people getting started with integrations or already using Workato
🔐 For companies with Pipefy Integrations enabled and the required access
🎯 For people who want to turn data into requests and track execution results
This content grew out of the live training session “How to build integrations with Pipefy’s native iPaaS,” held on Pipefy Academy and led by Guilherme Hora. The session featured two practical examples: turning rows from a CSV file into requests in Pipefy and communicating approval decisions through Slack.
By the end of this article, you will understand how connections, triggers and actions work together, how to use the data for each request and how to review executions when the outcome differs from what you expected.
📖 What you will learn:
Understand the logic before designing the flow
Pipefy Integrations is the native iPaaS module for connecting data and actions across tools. The training introduced three components.
Connection: authorizes access to a system. The Pipefy connector uses a Service Account with a Client ID and Client Secret. That account needs access to the pipes involved.
Trigger: is the event that starts a flow. In the examples, creating a card started file processing, while updating the evaluation field started the decision flow.
Actions: are the tasks that follow, such as retrieving information, creating a card, updating a manager or sending a message.
Before building, write a sentence that connects these parts: “When a file of requests arrives, create a card for each request and route the evaluation to that department’s manager.” It identifies the starting event, the outcome and the routing rule.
🔗 Learn more: read the introduction to Pipefy Integrations for an overview of the module.
Turn each row into a request
In the first demonstration, a card in an auxiliary pipe received a CSV attachment. The file contained 33 data rows with a full name, department, amount and request description. The flow read the file and iterated over the resulting list to create cards in the main pipe.
Consider a Procurement team receiving requests from IT, Engineering, Sales and Marketing. The file collects the requests, but each row needs to become a separate record with its own information and manager.
The key decision is where each value comes from. Inside a loop, the card creation action should use the current item. Each card then receives the name, department, amount and description for that request.
💡 Use a fixed value when every request should receive the same information. When requesters differ, use the current loop item. Selecting only the sample value can repeat the same name across the remaining cards.
After card creation, a Router separated the paths by department to assign a manager. The update used the ID of the card just created in the main pipe. That ID differs from the ID of the auxiliary card holding the file.
To adapt this example, define the columns that describe a request, the departments to recognize and the manager for each area. As an operational recommendation, provide a way to handle department values outside the expected set.
Connect the manager’s decision to Slack
In the second demonstration, updating the evaluation field started the flow. The decision followed an approval or rejection path, moving the card to the corresponding phase and sending a Slack message.
The approval message demonstrated how to include request details and the card link. For someone following the request in Slack, this brings the outcome and access to the record into one message.
When adapting this case, decide who needs the notification and which details help them act. A request identifier, the outcome and a card link provide context without reproducing every process field.
⚠ Use criteria that distinguish outcomes precisely. In Portuguese, “reprovado” also contains the sequence “aprovado”. Prefer explicit criteria for each complete value and test both paths. Handle any other states, such as an evaluation still in progress, separately.
This recommendation prevents every value other than an approval from being treated as a rejection. The rule should reflect the actual states in your process.
Test the complete path and review executions
During the demonstration, each step was tested to produce output data for later actions. A trigger based on a card event needs that event to occur in the pipe, such as creating a card or updating the selected field.
A test can also produce a real result. In the session, testing card creation created a card in the destination pipe. Use test data and check what has already been created before repeating a batch.
In Executions, Guilherme showed a successful run and another that stopped at card movement. The message indicated that the destination phase was not enabled among the source phase’s movement options. After adjusting that rule, he demonstrated a retry.
💡 Start with the first step that did not complete. If movement failed before the Slack action, investigate that step’s message. It helps locate the cause before reviewing the notification.
Movement rules remain part of the process. Read about moving cards through a pipe and restricting destinations to assess this scenario.
The demonstration also covered publishing changes: after editing the Slack message, Guilherme published the flow again so executions would use the new version. Before testing a change, check the published version and whether the flow is active.
Plan the transition if you use Workato
Connections, triggers and actions provide a familiar starting point for people who build Workato recipes. In the session, Guilherme highlighted Service Account authentication for the Pipefy connector and step testing to make data available throughout the flow.
For migration guidance, consult the official FAQ on moving from Workato to Pipefy iPaaS. The announced deadline is December 31, 2026. Connections must be recreated, and integrations may require adjustments and result validation.
The training provides a foundation for understanding and testing flows. Migration planning needs to account for your company’s specific integrations and access requirements.
Audience questions answered live
Do I need a personal token to connect Pipefy?
No. The Pipefy connector uses a Service Account with a Client ID and Client Secret. The training presented this as a way to associate integrations with a technical company account.
Who can create the Service Account?
A company Super Admin. Coordinate account creation and pipe access with the person responsible for that administration. See the Service Accounts documentation.
The connection exists. Why can’t the flow access one of the pipes?
Check the Service Account’s access to the pipe used by the trigger or action. In the demonstration involving two pipes, the account needed access to both the auxiliary and main pipes.
Why is trigger data unavailable for testing later actions?
For triggers based on card events, perform the corresponding event in the pipe during the test. A card creation trigger needs a new card; a field update trigger needs the configured update.
Why use CSV? Can I use connected spreadsheets?
CSV was chosen to demonstrate reading a file attached to a card. Guilherme also mentioned Google Sheets and Microsoft 365 connectors as alternatives, depending on the data source and available authentication.
How do I prevent every card from receiving the same data?
In the creation action inside the loop, use values from the current iteration item. In the demonstration, this gave each card the data from its own CSV row.
Which ID should I use to update each request’s manager?
Use the ID returned by the action that created that request in the main pipe. The auxiliary card’s ID identifies the record holding the file.
How can I assign a different manager for each department?
The example used a Router to select a path by department. Each path updated the manager of the newly created card. Adapt those mappings to your company’s departments and people.
Why didn’t the card move to the rejection phase?
In the demonstrated case, the destination was not enabled in the source phase’s movement options. Check the first failed step and its message in Executions to determine whether this applies to your case.
I edited the flow. Why does it still send the previous message?
In the training, the edited message took effect after the flow was published again. Check that the change was published and the flow is active before testing again.
Can I retry a failed execution?
The session showed retry options using the latest version and starting from the failed step. Before retrying, review completed steps to avoid creating cards or sending notifications again.
Do I need to migrate my Workato integrations?
Yes. Integrations using the Workato infrastructure provided through Pipefy must complete the transition by December 31, 2026. Read the Workato migration FAQ for responsibilities, connections and available assistance.
Before moving on, confirm that you understand
☐ Which event starts the flow and which pipes the Service Account needs to access.
☐ How to distinguish the current loop item from the card created in the main pipe.
☐ How to test approval and rejection and locate the first step that did not complete.
Ready to put this into practice? Choose a small set of test requests, define the expected outcome and use Getting Started with Pipefy Integrations to prepare the connection and validate your first flow.
