👤 For users with a process in production who need to share data with stakeholders outside the platform
🔐 Available on all plans (some approaches have limits that vary by plan)
🎯 For anyone who wants the right data to reach the right destination, at the right frequency, without exporting it by hand every week
Every Monday morning the same scene plays out. Someone on the team opens the process, builds the report, exports the file and emails it to a manager, a client or a supplier who does not live inside Pipefy. It is a small task, but it comes back every week, and when the person responsible takes time off or moves to another team, the data simply stops arriving. The stakeholder who relied on that number is left in the dark without knowing why.
By the end of this article you will know how to choose the right path so that data reaches its destination on its own, at the agreed frequency, and you will understand why the choice depends less on the urge to automate and more on three variables of your process: how much data, how often and where to.
📖 What you will understand here:
Before choosing the tool, understand what you are delivering
The most common mistake here is starting from the question "how do I schedule this?" when the right question is "what exactly needs to arrive on the other side?". A tracking number that fits in the body of an email is one thing. A living spreadsheet that the stakeholder opens and cross-references with their own data is another. A large volume of records feeding another department's financial system is something else entirely.
Each of these three situations has a natural path inside Pipefy, and choosing the right one from the start avoids the rework of building an automation that later fails to deliver what the stakeholder actually needed. The three sections below describe each path by what it solves well, not by the step-by-step configuration.
Option 1: automation sending card data by email
When what needs to reach the other side is a specific piece of data tied to a card, the most direct path is an automation that triggers an email template. You set up a rule in the format `[Specific Phase] Status notification -> Manager (External)`, and whenever the card meets the defined condition, the email goes out on its own to the recipient.
The decision point here is understanding what the email template carries: it takes the fields from that specific card, such as values, dates and assignees. It is the right choice when the stakeholder needs to know "this request was approved" or "this ticket changed phase", with the data from that unit of work.
This approach delivers card data, not a consolidated report. If what the stakeholder expects on Monday morning is an aggregate view of the whole process (how many cards in each phase, average time, weekly volume), the email template is not the path, because it does not embed the numbers from a report. In that case, go to Option 2 or 3.
- Learn more: the step-by-step setup for automations and email templates is in the Help Center, in the article Getting started with automations.
Option 2: API to move data to an external system
When the destination is another system (an ERP, a data warehouse, the company's own BI tool) and the data volume is significant, the Pipefy API is the path that gives real control over what leaves, when it leaves and in what format.
The decision criterion here is technical and you need it before promising a recurring delivery to the stakeholder: large API queries work with pagination, meaning the data comes back in blocks, not all at once. The larger your process volume, the more the integration needs to be designed to walk through those pages and reassemble the full set. It is not an obstacle, it is an architecture characteristic that separates an integration that handles process growth from one that breaks when the volume doubles.
The API is the right choice when there is a system on the other side that will consume and process the data, and when someone with a technical profile can maintain the integration. If the stakeholder is a person who just wants to open a spreadsheet and read, the API is too much force for the problem, and Option 3 solves it with less effort.
-
Learn more: for a one-off manual export of data to Excel and CSV, without integration, the path is the article How to export data from Pipefy to Excel and CSV.
Option 3: Integrations Hub writing to a Google spreadsheet
When the stakeholder only needs to open a spreadsheet and follow along, without editing anything back into the process, the Pipefy integration with Google Sheets through the Integrations Hub is the path of least friction. Pipefy writes the process data into the spreadsheet, and the stakeholder accesses that spreadsheet as a tracking source.
The decision criterion that avoids frustration here is understanding the direction of the integration: it is one-way. Pipefy writes to the spreadsheet, but it does not read back whatever the stakeholder might type there. The spreadsheet works as a read-only mirror of the process, not as an entry form. If your scenario requires the stakeholder to edit data that feeds back into the cards, this is not the path, and you are probably looking at a collection case that calls for a public form, not an export.
Google Sheets via the Integrations Hub is the right choice for the classic "I want my manager to see the updated numbers without asking me every week". It solves tracking, not two-way collaboration.
- Learn more: to understand when and why to use the Integrations Hub, see Pipefy Integrations Hub: what it is and when to use it.
The criterion that ties it all together: volume, frequency and destination
With the three approaches on the table, the decision becomes clearer when you answer three questions about your process, in this order:
- Where does the data go? If it goes to a person to read, think email (card data) or Google Sheets (aggregate tracking). If it goes to a system to consume, think API.
- How much data? Low, one-off volume works well with automation and with Google Sheets. High, recurring volume calls for the API, precisely because of the pagination that lets you walk through large sets without breaking.
- How often? And here comes the variable that tends to be forgotten: a recurring export built through automation consumes automation tasks, and that consumption depends on the process volume and the configured interval. The monthly task ceiling varies by plan, so an automation that runs very frequently over a high-volume pipe can consume far more than intuition suggests. It is worth sizing this before scheduling, so that the automatic delivery does not hit the plan limit halfway through the month.
Before moving on, make sure you understand:
☐ That choosing the path starts with the question "what needs to arrive on the other side", not "how do I schedule it"
☐ Which of the three approaches (card email, API, Google Sheets) fits the destination, volume and frequency of your case
☐ That a recurring export via automation has a consumption cost that must be sized against your plan limit
