Overview
Sharing workflows across workspaces allows organizations to centralize automation while enabling teams to run workflows in their own environments. The source workspace retains full ownership and editing control, while destination workspaces receive a runnable copy of the workflow. This approach helps reduce duplication, maintain consistency across environments, and simplify lifecycle management of shared automations.
Workflow ownership and update behavior
When a workflow is shared, it remains owned by the source workspace. Destination workspaces can run the workflow but cannot modify it.
Any published updates made to the workflow in the source workspace are automatically reflected in all destination workspaces. This ensures that improvements, bug fixes, and changes are consistently propagated without requiring manual synchronization.
If modifications are required in the destination workspace, users must create an independent duplicate of the shared workflow.
Shared dependencies and workflow components
When sharing a workflow, several related components may also be shared automatically.
Nested workflows: If the parent workflow calls other workflows, these nested workflows are automatically included in the share request and made available in the destination workspace.
Custom integrations and custom steps: Any custom integrations or custom steps used by the workflow are also shared with the destination workspace. Once shared, they can be used by other workflows in that workspace.
Integration and dependency requirements
For a shared workflow to run successfully in the destination workspace, all required dependencies must be available. These dependencies include:
Vendor integrations
Secrets
Step runners
There are two ways to ensure these dependencies are available:
Matching integrations already exist in the destination workspace with the same names used in the workflow.
The required integrations are shared with the destination workspace by the source workspace.
Verifying dependencies before accepting a share request helps ensure that the workflow executes correctly when triggered.
Prerequisites
Before sharing workflows across workspaces, ensure the following requirements are met:
Cross-workspace collaboration enabled: Contact Torq Support to enable cross-workspace sharing for your organization. Once enabled, authorized users can share resources across workspaces within the same organization.
Required permission: The user sharing the workflow must have a role that includes the
resource.sharescope. This permission is typically included in the Owner role.Automatic approval condition: If the user sharing the workflow is also an Owner in the destination workspace, the share request is accepted automatically.
Manual approval condition: Otherwise, the destination workspace owners receive an email requesting that they review and approve the shared workflow.
How to use
The following sections explain how to share workflows between workspaces, review and accept share requests, and manage shared workflows after they are distributed.
Share a workflow
Workflow sharing is initiated from the source workspace. You can share workflows manually from the UI or automate the process with the Create Share Request step.
Open workflows: Go to the Workflows page in the source workspace and locate the workflow you want to share.
Open sharing options: Open the workflow three-dot (...) menu and select Sharing.
Select destination workspace: Choose the workspace you want to share the workflow with, then click Share. You can only select from workspaces where you are a member.
Review dependencies: In the Workflow Dependencies tab, review the list of nested workflows that will be shared together with the selected parent workflow.
Submit the share request: Complete the sharing action.
If you are also an Owner in the destination workspace, the request is accepted automatically.
Otherwise, an email is sent to the destination workspace owners asking them to review and accept the workflow and any nested workflows included in the request.
Accept a share request
When a workflow is shared with your workspace, Torq sends an email notification to the destination workspace owners. Before accepting the request, review the workflow details and verify that all required dependencies are available so the workflow can run successfully in the destination workspace.
Open the request: In the email notification, click Review workflow.
Review workflow details: In Torq, review the shared workflow information. If the workflow includes nested workflows, they are listed as part of the request.
Decide on the request: Choose whether to accept or deny the shared workflow. The user who submitted the request is notified of your decision by email.
Verify required dependencies: Confirm that all integrations required for workflow execution are available, including vendor integrations, secrets, and runners. This can be achieved in either of the following ways:
The destination workspace already contains integrations with names matching those referenced in the workflow.
The required integrations are also shared with the destination workspace by the source workspace.
Confirm execution behavior: Once accepted, the workflow runs in the destination workspace when its trigger event occurs. The Shared column on the Workflows page indicates whether the workflow is shared to or from the workspace.
Understand access and updates:
Workflow execution details and run logs are available only in the destination workspace.
Published changes made in the source workspace are automatically reflected in the destination workspace.
The shared workflow cannot be edited in the destination workspace. To modify it there, create an independent duplicate.
(Optional) Automate decisions: Use the Accept Share Request or Deny Share Request steps to process share requests automatically.
Manage shared workflows
Shared workflows can be managed from either the source workspace or the destination workspace, depending on the action required. The source workspace can revoke access, while the destination workspace can remove the shared copy from its own workspace.
Revoke a shared workflow
Revoking a shared workflow removes access from the destination workspace. This action is performed in the source workspace.
Open workflows: Go to the Workflows page in the source workspace and locate the workflow you want to revoke. The Shared column should indicate that the workflow is shared from the workspace.
Open sharing options: Open the workflow three-dot (...) menu and select Sharing.
Review shared destinations: In the sharing modal, review the list of workspaces the workflow is currently shared with.
Revoke sharing: Remove the selected destination workspace from the sharing list.
Notify destination owners: An email is sent to the destination workspace owners informing them that the workflow was revoked.
Remove a shared workflow
Removing a shared workflow deletes the shared copy from the destination workspace. This action is performed in the destination workspace.
Open workflows: Go to the Workflows page in the destination workspace and locate the shared workflow. The Shared column should indicate that the workflow is shared to the workspace.
Remove shared workflow: Open the workflow three-dot (...) menu and select Remove shared workflow.
Notify source owners: An email is sent to the source workspace owners informing them that the shared workflow was removed.
Disable a shared workflow
Disabling a shared workflow prevents it from running in the workspace where it is disabled. This action does not affect copies of the workflow in other workspaces.
A shared workflow can be disabled independently in either the source workspace or the destination workspace. Disabling it in one workspace does not disable it elsewhere. For example, if the workflow is disabled in the source workspace, it can still continue to run in the destination workspace, and vice versa.
Use the Remove Workflow Sharing step to revoke or remove shared workflows automatically.
Keep the following behavior in mind when unpublishing shared workflows:
If you unpublish a shared workflow that uses a scheduled trigger, the copy in the destination workspace stops running.
If you unpublish a shared workflow that uses an integration trigger, system events trigger, or Torq cases trigger, the copy in the destination workspace continues to run.