👤 For pipe administrators replicating processes across organizations or business units
🔐 Available on all plans
🎯 For anyone who just received a cloned pipe and needs to understand what is ready and what still needs to be set up
Cloning a pipe is one of the fastest ways to replicate a working process to a new organization. But there is an important distinction that whoever receives the clone needs to understand: cloning is not duplicating everything. It duplicates the structure.
That distinction becomes clear when the team starts operating and finds that automations do not fire, database connections do not exist, and members need to be invited from scratch. This is not a process failure: it is the expected behavior of cloning. Knowing what comes along and what does not saves hours of troubleshooting.
By the end, you will know exactly what to check before putting the cloned pipe into production.
📖 What you will learn here:
What comes along in the clone?
Cloning transfers the process structure. Everything that defines how the pipe works, but not who operates it or the data already in it.
What is copied:
- Phases: all phases from the original pipe, with their names and configurations.
- Fields: all fields in each phase and in the start form, including type, name, and required settings.
- Labels: label-type fields are cloned. Label configurations (name, color) may vary depending on the plan and destination organization. Review and adjust after cloning if needed.
- Conditional fields: conditional display rules are cloned. Note: if the condition reference is a connection field, it arrives blank in the clone.
- Email templates: email templates configured in the pipe are transferred.
- Native automations: automation rules created directly in the pipe are cloned, including their names, including their names, which also receive the "(Copy 1)" suffix. There are important exceptions covered in the automations section below.
- SLA configurations: SLAs configured at the pipe level (expiration time) and at the phase level (delay time) are cloned along with the structure.
The cloned pipe receives the suffix "(Copy 1)" in its name. Rename it before sharing with the team to avoid confusion with the original.
What is not transferred and needs to be reconfigured?
Everything that connects the pipe to the outside world (people, systems, and data) is not cloned. These elements are specific to each organization and must be configured manually at the destination.
- Members and permissions: the cloned pipe arrives with no members other than whoever performed the clone. Invite the team and set permission levels before going live.
- Database connections: connected databases are cloned and remain connected in the destination organization. What is not transferred is the content: existing records inside the databases do not come with the clone. The databases arrive empty and need to be populated in the new organization.
- Integration Hub integrations: integrations set up through Pipefy iPaaS must be rebuilt from scratch in the cloned pipe, including downloading and uploading integration files and creating connections with the new organization's credentials.
- Public forms: the public form link is not transferred. If the process receives requests through a public form, you need to activate and share a new link in the cloned pipe.
- Cards and history: the clone starts without data. Cards existing in connected pipes are not transferred. Database records arrive empty. Activity history is not cloned. The cloned pipe is a clean structure, ready to operate with new data.
- Pipe description: the description text configured in the pipe's information settings is not transferred. Rewrite the description in the cloned pipe to give the destination team the right context.
- Interfaces: interfaces configured in the original pipe are not cloned and must be created again at the destination.
- Portal: portals associated with the pipe are not transferred. Set up the portal again in the destination organization.
- AI Assistant: AI Agent configurations linked to the pipe are not cloned. The assistant must be configured from scratch in the cloned pipe.
- Dashboards and reports: dashboards and reports created in the original pipe do not come with the clone. Recreate the necessary views in the destination organization.
- PipeSign settings: digital signature configurations are not transferred. Reconfigure PipeSign in the cloned pipe as needed.
Before inviting the team and starting operations, complete the database and integration configuration. A pipe with automations that read database content will work structurally, but rules that depend on specific records will find no data until the databases are populated in the new organization.
Why can automations arrive broken?
This is the point that causes the most confusion after a clone. Automations are copied, but they may not work correctly in the cloned pipe for two reasons:
Automations that depend on connection fields
If an automation uses a connection field as a trigger or condition, it is cloned without that field. The rule exists in the pipe, but the reference to the field is empty. Result: the automation does not fire when it should, or fires incorrectly.
How to identify: open the automations in the cloned pipe and look for rules with blank fields in the conditions or actions. Automations with HTTP actions (calls to external APIs) are also cloned, but authentication tokens and credentials are not transferred. Reconfigure tokens before activating those automations at the destination. Any blank field where a reference should exist signals an automation broken by a missing connection dependency.
Automations with conflicting required fields
If a form field was marked as required after the automation was created, and the autofill for that field in the rule is blank, Pipefy does not clone that automation. It simply does not appear in the cloned pipe.
How to identify: compare the number of automations in the original pipe with the number in the clone. Any difference means one or more rules were dropped during cloning.
Before cloning a pipe with complex automations, map which automations depend on connection fields. Those will need to be reconfigured manually at the destination.
How does cloning work with connected pipes?
If the pipe you are cloning has connections to other pipes, here is what happens:
Connected pipes are "cloned" together automatically: when two pipes are connected to each other, cloning one brings the other along. You do not need to clone them separately.
Automations referencing other pipes do not drag them along: if an automation refers to another pipe but the two do not have a configured connection field, only the original pipe is cloned. The referenced pipe does not come along.
A pipe connected to itself blocks cloning: if the pipe has a field connected to itself, cloning is blocked. Remove that connection, clone the pipe, and reconfigure the self-connection at the destination.
Check whether the pipe has conditional fields that reference connection fields before starting the clone. Those conditionals arrive blank and must be reconfigured manually.
Post-clone checklist: what to configure before going live
Use this list after receiving the cloned pipe and before starting operations:
Structure
☐ Rename the pipe (remove the "Copy 1" suffix and adapt for the destination organization)
☐ Review phases and fields: confirm they make sense for the destination BU context
☐ Check conditional fields: reconfigure any that arrived blank due to missing connection dependencies
Automations
☐ Compare the number of automations in the original and the clone: identify which ones were dropped
☐ Open each automation and check for blank fields in conditions or actions
☐ Reconfigure automations broken by missing connection fields
☐ Adjust email triggers, SLA alerts, and movement rules for the destination organization's business rules
Connections and integrations
☐ Verify that the databases were cloned and are correctly connected
☐ Populate the cloned databases with content in the destination organization
☐ Reconfigure Integration Hub integrations (download, upload, and reconnect with the new organization's credentials)
☐ Recreate interfaces, portal, and dashboards needed in the destination organization
☐ Configure AI Agent and PipeSign if the process uses those features
Access and operations
☐ Invite team members and set permission levels
☐ Activate and share the public form link if the process receives requests through that channel
☐ Run a full test with a sample card before announcing the pipe to the team
