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

# Collections

> Group related Ravenna workflows into collections by team, department, or business process to keep automation organized as your library grows.

Organize related workflows using collections. Group automation by team, department, or business process to keep workflows manageable as the number of workflows grows.

<View title="Human" icon="user">
  ## Creating collections

  <Steps>
    <Step title="Navigate to workflows">
      Open **Workflows** from your workspace sidebar
    </Step>

    <Step title="Create collection">
      Click **New Collection** and provide a clear name
    </Step>

    <Step title="Add description">
      Explain what types of workflows belong in this collection
    </Step>

    <Step title="Customize appearance">
      Add an icon, emoji, or color to make the collection easily identifiable
    </Step>

    <Step title="Set parent collection">
      Optionally nest this collection under a parent for hierarchical organization
    </Step>
  </Steps>

  ***

  ## Organization strategies

  Select an approach that matches your team structure and workflow needs.

  <AccordionGroup>
    <Accordion title="By department">
      Organize collections by team or department. Each team manages its own automations.

      **Example structure:**

      * IT Operations (Server Monitoring, User Onboarding, Security Alerts)
      * HR Processes (Employee Onboarding, Time Off Requests, Performance Reviews)
      * Customer Support (Ticket Routing, Escalations, CSAT Surveys)
    </Accordion>

    <Accordion title="By process">
      Organize collections by business function. Works well when teams share automation across processes.

      **Example structure:**

      * Incident Management (Alert Routing, On-Call Escalation, Post-Incident Workflows)
      * Access Management (User Provisioning, Access Requests, Offboarding)
      * Ticket Management (Auto-Assignment, Status Updates, Notifications)
    </Accordion>

    <Accordion title="By integration">
      Organize collections by external system. Works well when workflows are focused on specific integrations.

      **Example structure:**

      * Jira Workflows (Issue Creation, Status Sync, Escalations)
      * Okta Workflows (User Provisioning, Group Management, Access Reviews)
      * Slack Workflows (Notifications, Approvals, Alerts)
    </Accordion>
  </AccordionGroup>

  ***

  ## Collection hierarchy

  Collections support nested structures that mirror your organization or business processes. Create hierarchical structures by nesting collections: parent collections contain related child collections, and you can reorganize by changing parent-child relationships at any time.

  **Example:** An "Engineering" parent collection contains "Backend", "Frontend", and "DevOps" child collections.

  ***

  ## Managing collections

  ### Editing collections

  Update collection name, description, appearance, or parent relationship at any time. Changes do not affect workflows within the collection.

  ### Moving workflows and collections

  Move workflows and collections between locations as processes change.

  **Drag and drop:**

  1. Click and hold on a workflow or collection
  2. Drag to the target collection or breadcrumb
  3. Release to move

  To move multiple items, select them using checkboxes, then drag any selected item. All selected items move together. You can also drag items to the "Move to new folder" button to create and move in one action.

  **Bulk move:**

  1. Select workflows or collections using checkboxes
  2. Click the **Move** action in the toolbar
  3. Select the target collection and confirm

  **Move restrictions:**

  * Workflows retain their history and configuration when moved
  * Collections cannot be moved into their own subcollections (prevents circular references)
  * Moving a collection also moves all workflows and subcollections within it

  ### Duplicating workflows

  Copy an existing workflow to use as a starting point for a new one. The original workflow is unchanged. The copy is independent — editing one does not affect the other.

  **Duplicate within the same workspace:**

  <Steps>
    <Step title="Open the workflow row menu">
      In the workflows table, hover over a workflow and click the three-dot menu.
    </Step>

    <Step title="Select Duplicate">
      Provide a name, optional description, and target collection for the copy.
    </Step>

    <Step title="Open the new workflow">
      The duplicate is created in **Draft** state with all steps, configuration, and dynamic value references intact. [Publish it](/documentation/automate/workflows/publish) when ready.
    </Step>
  </Steps>

  **Duplicate to another workspace:**

  Use **Duplicate to Workspace** to share a workflow design across workspaces in the same organization — for example, when rolling out a proven automation from one team to another.

  <Steps>
    <Step title="Open the workflow row menu">
      In the workflows table, hover over a workflow and click the three-dot menu, then select **Duplicate to Workspace**.
    </Step>

    <Step title="Select the target workspace">
      Select any workspace where you are a member (Guest memberships are not eligible). Provide a name and optional description.
    </Step>

    <Step title="Reconnect workspace-specific references">
      The copy is created in the target workspace in **Draft** state. Open it and reconnect any workspace-scoped references before publishing.
    </Step>
  </Steps>

  <Info>
    Cross-workspace duplication clears references to workspace-scoped resources: queues, statuses, tags, request types, categories, SLAs, task templates, and Slack channels. Organization-scoped references are preserved, including users, user groups, applications, access levels, access policies, code actions, and approval templates.
  </Info>

  ### Deleting collections

  Deleting a collection also deletes all workflows within it.

  <Warning>
    Collection deletion is permanent and affects all contained workflows. Export or move workflows before deleting if you want to preserve them.
  </Warning>

  ### Permissions

  Control who can create, edit, or delete workflows within collections based on workspace roles and permissions.

  ***

  ## Tips

  * **Use descriptive names.** Choose names that clearly indicate the collection's purpose. Avoid vague names like "Misc" or "Other" that become catch-alls.
  * **Keep hierarchy shallow.** Limit nesting to 2-3 levels deep. Deeper hierarchies become difficult to navigate.
  * **Indicate ownership.** Use the description field to note which team or person owns each collection.
  * **Review regularly.** Periodically remove unused collections, consolidate similar ones, and update descriptions as processes evolve.
  * **Start simple.** Begin with a basic structure and add complexity only as needed. Splitting collections is easier than merging them.

  <Callout icon="link" color="#6B7280">
    Learn more about [building workflows](/documentation/automate/workflows/workflow-builder) and [publishing workflows](/documentation/automate/workflows/publish)
  </Callout>
</View>

<View title="Agent" icon="bot">
  ## Collections overview

  Collections are folders that organize workflows. They support unlimited nesting, custom icons and colors, and descriptions. Each workflow belongs to zero or one collection.

  ***

  ## Organization recommendations

  **By department** works best when teams own their automations independently. Each team manages workflows in their collection without affecting others. Example: IT Operations, HR Processes, Customer Support as top-level collections.

  **By process** works best when workflows span teams. Group all workflows related to a business function together regardless of which team owns them. Example: Incident Management, Access Management, Ticket Management as top-level collections.

  **By integration** works best when workflows are tightly coupled to specific external systems. Group all Jira-related workflows together, all Okta workflows together, etc.

  **In practice,** most organizations use a hybrid: top-level collections by department or process, with subcollections for specific integrations or sub-processes within each.

  ***

  ## Hierarchy best practices

  * Keep nesting to 2-3 levels. Deeper hierarchies become hard to navigate.
  * Use descriptive names that indicate purpose, not vague labels like "Misc" or "Other."
  * Note ownership in the collection description (which team or person is responsible).
  * Review and consolidate periodically. Remove empty collections and merge overlapping ones.

  ***

  ## Duplicating workflows

  Two duplication options are available from the workflow row menu:

  * **Duplicate.** Creates a copy in the same workspace. All steps, configuration, and dynamic value references are preserved. The copy is created in `Draft` state.
  * **Duplicate to Workspace.** Creates a copy in another workspace within the same organization. The user must be a non-Guest member of the target workspace. Workspace-scoped resource references — queues, statuses, tags, request types, categories, SLAs, task templates, and Slack channels — are cleared on the copy. Organization-scoped references — users, user groups, applications, access levels, access policies, code actions, and approval templates — are preserved. Cross-organization duplication is not allowed.

  In both cases the copy is independent. Editing the original does not affect the copy.

  ***

  ## Constraints

  * Deleting a collection deletes all workflows within it. Move workflows out before deleting if you want to preserve them.
  * Collections cannot be moved into their own subcollections (prevents circular references).
  * Moving a collection moves all contained workflows and subcollections with it.
  * Workflows retain their configuration and execution history when moved between collections.
</View>