Link Menu Expand (external link) Document Search Copy Copied
This website is for Zenphi public documentation.

Moving a Flow Between Spaces

Definition

The Move Flow feature allows you to seamlessly migrate an existing automation flow from one Space to another within the same Zenphi Workspace.

In a well-organized workspace, you often have distinct Spaces for different functions (e.g., “HR,” “Finance,” “Sandbox”). As workflows evolve, they may need to change locations—moving from a testing environment to a production environment, or being reorganized into a more appropriate department folder.

Previously, moving a flow required a manual “Export to JSON” and “Import” process, which severed connections and required reconfiguration. The Move Flow tool replaces this with a single-click action that performs a “Lift and Shift” operation.

Key Capabilities:

  • Zero Re-Configuration: Unlike importing, moving a flow preserves all connection settings, trigger authentications, and variable mappings. No post-move setup is required.
  • Zero Downtime: If the flow is currently Published, it remains published and active in the new location. You do not need to stop or restart the automation.
  • Preserved Dependencies: The flow maintains its internal links to assets in the original space (such as Zenphi Tables), allowing for advanced distributed architectures.

Use Cases

  1. The “Sandbox to Production” Deployment:
    • Scenario: A user builds and tests a complex automation in their private “Personal Space” or a dedicated “Dev” space. Once it is working perfectly, they move it to the shared “Finance” or “HR” space so the whole team can see and manage it.
  2. Organizational Cleanup (Refactoring):
    • Scenario: A team started with just one generic “Default Space.” Over time, it got cluttered with 50+ flows. They create new spaces (e.g., “Onboarding”, “Invoicing”) and need to migrate existing flows into these new homes to organize the workspace.
  3. The “Accidental Creation” Fix:
    • Scenario: A user starts building a flow, gets deep into the logic, and suddenly realizes, “Oh no, I’m in the wrong space.” Instead of starting over or doing the export/import dance, they just move it.
  4. Distributed Architecture :
    • Scenario: You want to keep your Data centralized but your Logic distributed. You keep a master “Employee Database” Zenphi Table in a locked-down “Data Space,” but you move the specific “Leave Request” flow to a “General” space. The flow runs in “General” but still writes to the table in “Data Space.”

Prerequisites

To perform this action, you must hold the Designer or Owner/Administrator role within the Workspace.

Since Roles in Zenphi are assigned at the Workspace level, having these permissions automatically grants you the ability to manage flows across all Spaces within that Workspace.

How to Move a Flow

The process is initiated from the Destination Space (the place where you want the flow to end up).

  1. Navigate to the Space where you want the flow to be moved TO.
  2. Click the Create Flow button (just as you would when starting a new project).
  3. In the template selection screen, look at the top right corner. Click the Move Flow button.
  4. A dialog will appear listing flows from your other spaces. Select the flow you wish to transfer.
  5. Confirm the selection.

Result: The flow is immediately removed from the source space and appears in your current space, retaining its status (Draft or Published).

Note: You can access the “Move Flow” button anywhere the Create Flow button appears in the UI, ensuring you can quickly reorganize from any view.

Important Considerations

1. Move vs. Copy

Please be aware that this is a transfer action, not a duplication.

  • Move Flow: The flow leaves Space A and enters Space B. It no longer exists in Space A.
  • Export/Import: If you need the flow to exist in both spaces simultaneously (cloning), you should continue using the Export/Import method.

2. The “Cross-Space” Data Advantage

One of the most powerful aspects of the Move Flow tool is how it handles Zenphi Tables.

By default, a flow in “Space B” cannot see or interact with a Table that lives in “Space A.” However, the Move tool creates a special exception:

  • The Scenario: You build a flow in “Space A” and connect it to a Table in “Space A.”
  • The Move: You move the flow to “Space B.”
  • The Result: The flow remembers its connection to the Table in “Space A.” It will continue to read and write data to that table successfully, even though that table is technically invisible to other flows in Space B.

This allows you to create Distributed Architectures: keeping your master data tables secure in a locked-down space while moving the operational flows into public spaces for team visibility.

Example Scenario: The “Sandbox to Production” Deployment

The Goal: You are an Automation Engineer building a complex “Expense Approval” workflow. You do not want the Finance team to see the flow while it is half-finished and full of test data.

The Process:

  1. Build in Sandbox: You create the flow in your private “Sandbox Space.” You connect it to your Google Sheets and test the logic until it works perfectly.
  2. Deploy to Production: Now that it is ready for the team, you navigate to the “Finance Space.”
  3. Initiate Move: You click Create Flow > Move Flow and select the “Expense Approval” flow from the Sandbox list.
  4. Outcome: The flow instantly jumps to the Finance Space. It is already Published, the Google Drive connections are already active, and your team can immediately start using it without you having to re-authenticate a single step.