👤 For all users
🔐 Available for Business, Enterprise, and Unlimited plans
🎯 For anyone who manages two or more interdependent processes
Purchasing approves the request, but finance only finds out when someone remembers to tell them. IT receives the access request, but the onboarding card stays in the wrong phase because no one updated it. Two processes that should communicate end up depending on manual intervention to exchange information.
Automations between pipes solve this. By the end of this article, you'll know when connecting two pipes makes sense, how the parent child model works in practice, and which configuration decisions determine whether the orchestration will work or generate rework.
📖 What you'll understand here:
When connecting pipes makes sense (and when it doesn't)
Connecting two pipes is the right answer when the process changes scope or the team responsible changes. An approved purchase request that needs to become a recorded expense in finance. A candidate hired in the recruiting pipe who needs to start onboarding in another pipe. A resolved IT ticket that needs to notify the asset management process.
The sign that you need connected pipes is clear: a team needs to act on information that originated in another process, and today that depends on someone copying, pasting, or notifying manually.
Connecting pipes doesn't make sense when the process is the same, just with more phases. If a single team follows the flow from start to finish and the steps have natural continuity, the right path is to add phases to the existing pipe. The connection introduces configuration and maintenance complexity that isn't justified when a single pipe solves it.
Practical criterion for deciding: Is there a change in the responsible team, a change in scope, or a one to many relationship between the cards? If yes, connected pipes. If no, additional phases in the current pipe.
The parent child model: how it works
When two pipes are connected, a card in one pipe can automatically create a card in the other. The card that triggers the creation is called the parent. The card created in the second pipe is the child.
The child card is not a copy of the parent. It's a new demand, in another process, with its own lifecycle. What links them is the connection: the parent knows it has children, and the children know which parent they came from.
Three essential behaviors to know before configuring:
Only the fields mapped in the automation are transferred
The connection between the pipes doesn't transfer fields automatically. You define, field by field, what passes from the parent card to the child at the moment of creation. Fields that aren't mapped arrive blank on the child.
The child card doesn't follow changes on the parent
Once the child is created, it has its own life. If the parent moves forward or back a phase, the child isn't updated unless there's an explicit automation configured for that.
The "all children in a phase" trigger requires 100% completion
The event that fires when all connected cards reach a phase requires exactly that: all children in that phase. If two out of three children arrive, the trigger doesn't fire. Deleted child cards stop counting toward this calculation.
Example: recruiting that triggers onboarding
An HR team has two pipes: Recruiting and Onboarding. When a candidate is approved, onboarding needs to start in a separate pipe, with another team and another workflow.
The configured automation: when a card enters the "Approved" phase in the Recruiting pipe, create a connected card in the Onboarding pipe. Mapped fields: employee name, start date, department, and responsible manager.
What happens: the child card is created in the Onboarding pipe with the essential information already filled in. The team responsible for onboarding receives the demand without needing anyone to notify them. The parent card keeps the link to the child, making it possible to track onboarding status without leaving the Recruiting pipe.
What doesn't happen automatically: if the parent card goes back to "Pending Documentation" because a document was missing, the child card in Onboarding doesn't stop. To pause or update the child, a second explicit automation needs to be configured.
Mandatory order: the connection between the pipes needs to be configured before creating the automation. Trying to create the automation without the connection active will prevent the destination pipe from showing up as an option. Connection first, automation after.
Best practices for dependencies between pipes
Map the fields before you start
Open both pipes side by side and decide which fields from the parent need to reach the child before configuring any automation. Blank fields on the child card generate manual rework, which is exactly what the automation was supposed to eliminate.
Avoid loops between pipes
If the child pipe has an automation that, when creating a card, triggers something in the parent pipe, which in turn creates another child, you have a cycle. Use conditions or control fields to make sure automations between pipes only fire once per demand.
- Recommended strategy: create a selection field on the child card with the value "originated by automation" and use that as a negative condition in the parent pipe's automations.
- Alternative: add a condition to the automation that checks whether the child card already exists before creating another one.
Test with real cards before activating
Create a test card in the parent pipe, trigger the phase that fires the event, and check whether the child card was created with the correct fields. Mapping errors only show up in practice and, in high volume processes, can generate dozens of cards with incorrect data before they're noticed.
Document the field mappings
A pipe can be connected to multiple other pipes at the same time. The more connections and cross automations, the greater the maintenance complexity. Any change to a mapped field can silently break the flow. Record which fields from which pipes are connected and through which automation.
The automation runs with system privileges, regardless of the permissions of the user who created the parent card. A member with no access to the child pipe doesn't prevent the child card from being created. Useful for processes with separate teams, but it requires attention: document the mapped context fields so the destination team understands where each card came from.
Antes de avançar, confirme que você entende:
☐ When it makes sense to connect two pipes versus adding phases to the current pipe
☐ The difference between parent and child cards and what connects them
☐ Which transferred fields need to be explicitly mapped in the automation
☐ That the child card does not automatically update when the parent changes phases
☐ The correct order: setting up the connection before creating the automation
