👤 For people who run pipes and administer processes
🔐 Features depend on your company plan and permissions
🎯 For people connecting requests, managing access and organizing approvals
A request can involve several teams, create work in another process and require approval from someone who follows multiple pipes. These situations shaped the Pipefy Academy session “Pergunte ao time Pipefy: automações e permissões em foco,” held on October 28, 2026. Felipe Borer led the demonstrations, hosted by Renata Lapetina, using a request process and a separate process for analyst tasks. The session was delivered in Portuguese.
By the end of this article, you will know how to identify where an automation starts, distinguish a trigger from a condition, review access and assess a centralized view for requesters and approvers.
To join upcoming sessions and bring your questions, explore the Pipefy Academy live training schedule, available in Portuguese.
📖 What you will learn:
Connect requests to tasks in another pipe
One question collected from the Community asked where to configure a rule when a request needs to generate work in another pipe. Felipe began with the event that initiates the action.
In the example, Requests was the main process and Analyst tasks held the related work. If creating a request should create a task, the event occurs in the Requests pipe. The action creates a connected card in the task pipe. If the event you are monitoring is task creation, the rule starts in the pipe where that task is created.
This distinction helps define the relationship between the main request, called the parent card, and the resulting work, called the child card. Before configuring the rule, identify where the event occurs, which card will be created or updated and which information should travel with it.
To create connected cards, the pipes must already be connected. Also check field mapping and whether required destination data will be available when the card is created.
Write the rule as a sentence first. For example: “When a request is created, create a connected task for the analyst.” Then confirm that the source, destination and transferred data match that intention.
- Learn more: read how to create automations for connected cards, available in Portuguese.
Move cards when the process condition is met
The next question concerned moving cards automatically based on a triage field. In the demonstration, the request classification determined the route. The example used “Bug” to illustrate movement to the completed phase.
That destination belonged to the demonstration. When adapting the logic, choose the phase that represents the next activity or the actual completion of your process.
The rule involves three decisions. The trigger is an update to the classification field. The condition checks whether its value matches the intended category. The action moves the card to the selected phase. Monitoring a field update alone does not distinguish its possible answers.
Another question asked where to define the destinations allowed from a phase. Movement settings and required fields also need to reflect the path your team has agreed upon.
For more context, read How automations work in Pipefy. For configuration, see creating an automation to move cards and movement controls between phases. These resources are in Portuguese.
Want practice with a complete workflow? The course Faça o trabalho rodar sozinho, delivered in Portuguese, includes exercises on triggers, conditions and actions.
Add labels while preserving existing ones
A request may have several classifications. The Community asked how to add a new label without removing labels already attached to the card.
Felipe presented an alternative in Pipefy Integrations using an addition operation. The key distinction is between appending an item and replacing the field content. To retain earlier classifications, the operation needs to preserve that list.
The API documentation confirms incremental field updates using ADD in updateFieldsValues. For labels, the value uses the identifier of an existing label. This confirms that incremental addition is supported; integration configuration must account for the card, field and label identifiers in your process.
Before using the flow with real requests, test a card that already has labels. Confirm that the new classification was added and the earlier labels remain.
- Learn more: see the incremental field update documentation. For labels in native automations, read how to add labels automatically, available in Portuguese.
Review who needs access to each request
Belonging to a company in Pipefy and having access to a pipe are separate considerations. In the session, a question about accessing pipes led to a review of process privacy and invited members.
For a private pipe, check whether that person has access to the process. For people working on requests, choose a role based on which cards each person needs to view or edit.
Restricted view allows people to create cards and view or edit cards they created or are assigned to. This provides an option for analysts who should follow only their own requests. Read only access allows people to see all cards and comment without editing their content.
When discussing attachments, Felipe recommended starting with card access. For a process containing sensitive documents, assess the information each role needs and validate the experience using that role.
A filter applied by an administrator does not demonstrate another user's access. The training used a filter to illustrate a subset of cards; verifying permissions requires checking the role actually granted.
- Learn more: review pipe roles and permissions, available in Portuguese. Access levels depend on the contracted plan.
Organize tracking with Interfaces
Requesters and process operators may need different views. A requester may only need to follow a submission. A director may need to find decisions awaiting their approval across several pipes.
Felipe demonstrated Interfaces as a way to organize that information. A page can gather data from different processes, with conditions controlling which records appear and customized details for each request.
To adapt the example, define who can access the Interface, which records each person needs and which fields they can view or edit. The documentation describes the current user filter for personalizing visibility. A fixed filter containing one approver's name illustrates a different use from a page that adapts to whoever opens it.
Start with the decision the person needs to make. For an approval, a request identifier, supporting context and a decision field can guide the view. Validate that selection with the people who will use the page.
- Learn more: read Getting started with Interfaces.
Audience questions answered live
Alongside questions collected from the Community, two audience questions introduced situations from a participant's operation.
How can the card title use information from different fields?
The participant managed reimbursements and third party payments in the same pipe. One path used the employee's details; the other used the supplier's. Choosing only one field as the title left the other path without the expected identification.
Felipe proposed putting the result in an auxiliary field and using that field as the title reference. Following the naming standard, it could be called [Auxiliary] Title. The rule should populate it with the information appropriate to the request type.
The session also suggested combining the two values when only one field is filled. Before adopting that variation, test both request types and define what should happen when both fields are filled or both are empty. This solution was proposed live and left for testing in the participant's process.
- Learn more: see card title settings in pipe preferences, available in Portuguese. Changing the reference field applies to new cards.
How can approvals from several pipes be brought together?
The participant reported that the CEO and managers received communications but still needed to open individual pipes to find approvals. Felipe suggested reviewing the configured recipient and demonstrated an Interface to gather requests relevant to the approvers.
The proposed approach was an approval view containing the relevant processes, with record visibility defined for each person. The page can provide the details needed for the decision.
The session did not confirm why items were missing from Tasks and requests. For a similar case, collect a sample card, the expected recipient and the rule used to request the action. These details support investigation while you assess whether an Interface meets the need for a centralized view.
Before moving on, confirm that you understand:
☐ Which pipe contains the event that starts each rule.
☐ Which condition distinguishes cards that should follow each route.
☐ The difference between filtering a view and granting permission.
☐ How to validate titles and approval views with examples from your process.
Ready to apply what you learned? Choose one rule in your process, define the expected result and continue with How automations work in Pipefy, available in Portuguese, to organize the trigger, condition and action before configuring it.
Which of these situations comes up in your work? Share the context and the outcome you want in the comments to continue the conversation with the Community.
