> ## Documentation Index
> Fetch the complete documentation index at: https://docs.serval.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Duplicate Workflows

> Copy workflows within a team or across teams to reuse automations

Duplicate workflows to reuse automations across teams without rebuilding from scratch. Each copy is independent—you can customize it for the target team's needs.

## When to Duplicate

| Scenario                           | Example                                         |
| :--------------------------------- | :---------------------------------------------- |
| **Same workflow, different teams** | IT and HR both need a user offboarding workflow |
| **Template for variations**        | Base "send report" workflow customized per team |
| **Testing changes safely**         | Copy production workflow to test modifications  |
| **Sharing best practices**         | Replicate a successful workflow to other teams  |

***

## Duplicate a Workflow

<Steps>
  <Step title="Open the workflow">
    Navigate to the workflow you want to duplicate
  </Step>

  <Step title="Open the menu">
    Click the **...** menu in the top right corner of the workflow
  </Step>

  <Step title="Select Duplicate">
    Click **Duplicate** or **Duplicate to team**
  </Step>

  <Step title="Choose the target team">
    Select which team should receive the copy. You can duplicate to:

    * The same team (creates a copy you can modify)
    * A different team (where you have manager rights)
  </Step>

  <Step title="Confirm">
    Click **Duplicate** to create the copy
  </Step>
</Steps>

The new workflow opens in the builder, ready for customization.

***

## What Gets Copied

| Copied                  | Not copied                        |
| :---------------------- | :-------------------------------- |
| Workflow code and logic | Run history                       |
| Name and description    | Version history                   |
| Input configuration     | Published state (starts as draft) |
| Approval settings       | Schedule (must be reconfigured)   |
| Execution scope setting | Webhook URL (new one generated)   |

<Note>
  The duplicated workflow starts as a draft. Review the configuration and publish when ready.
</Note>

***

## After Duplicating

### Check integrations

The target team must have access to the same connected applications. If the workflow uses Okta, GitHub, or other integrations, verify:

1. The target team has the integration connected
2. The integration has the required permissions
3. Any referenced resources (groups, repos, etc.) are accessible

<Warning>
  Workflows will fail if they reference integrations the target team doesn't have. Check the workflow's connected apps before publishing.
</Warning>

### Update team-specific references

Some values may need updating for the new team:

* Slack channel names or IDs
* Group names or IDs
* Email addresses or distribution lists
* Resource identifiers

### Reconfigure triggers

Certain triggers need reconfiguration after duplication:

| Trigger type    | After duplication                                 |
| :-------------- | :------------------------------------------------ |
| Manual          | Works immediately                                 |
| Scheduled       | Must set up schedule again                        |
| Webhook         | New webhook URL generated—update external systems |
| Event-triggered | May need to reconfigure event filters             |

### Adjust execution scope

Review who should run this workflow in the new team:

* **Anyone in the org** — Available to help desk agent for all users
* **Team members only** — Restricted to the target team

***

## Keeping Duplicates in Sync

Duplicated workflows stay linked to the original. When the source workflow is updated, you can pull those changes into your copy.

### Pull updates from the original

When the source workflow has new versions available:

1. Open the duplicated workflow
2. You'll see a notification that updates are available
3. Review the changes from the source
4. Choose to pull the update or keep your current version

This lets teams benefit from improvements to the original while maintaining their own copy.

### When to pull vs. customize

| Scenario                                        | Recommendation                  |
| :---------------------------------------------- | :------------------------------ |
| Source workflow fixed a bug                     | Pull the update                 |
| Source added a feature you need                 | Pull the update                 |
| Your team needs different behavior              | Keep your version and customize |
| Source changed something that breaks your setup | Keep your version               |

<Tip>
  Pull updates regularly to stay current with bug fixes and improvements from the source workflow.
</Tip>

***

## Permissions

To duplicate a workflow:

* **To the same team** — You need edit access to the team
* **To a different team** — You need manager rights on the target team

You can only duplicate to teams you have permission to manage.

***

## Best Practices

<CardGroup cols={2}>
  <Card title="Name clearly" icon="tag">
    Update the name to reflect the team or purpose: "IT User Offboarding" vs "HR User Offboarding"
  </Card>

  <Card title="Review before publishing" icon="magnifying-glass">
    Check all references, integrations, and settings before making the workflow available
  </Card>

  <Card title="Document changes" icon="file-lines">
    Note in the description what was customized from the original
  </Card>

  <Card title="Test thoroughly" icon="vial">
    Run the workflow manually to verify it works in the new team context
  </Card>
</CardGroup>