Moving tickets between teams

Moving tickets between teams enables the transfer of tickets between different teams within your organization based on business rules, escalation needs, or specialized expertise requirements. The process maintains communication continuity, preserves all ticket history and context, and ensures proper ownership handoff. This feature is essential for organizations with specialized teams that need to collaborate on customer issues.

​

How moving tickets works

When you need to move a ticket from one team to another, the platform creates a new ticket in the destination team while preserving all context and communication history from the original ticket.

​

The process

1. Ticket archival and creation

• The original ticket is archived and transfer details are logged in the ticket’s activity
• A new ticket is created in the destination team with all relevant context
• Both tickets are automatically linked as related tickets for complete audit trail
• The archived ticket can be unarchived if moved back to the original team, otherwise remains for reference only

2. Data and context transfer

• All conversation history is copied to the new ticket
• Custom field values are mapped between team forms where compatible
• File attachments and internal notes are transferred
• Customer communication channels are redirected to the new ticket

3. Team transition

• Destination team receives immediate ownership and notification
• Team-specific workflows, SLAs, and auto-responders are applied
• SLA of the source team is paused and CSAT is cancelled

​

Benefits

• Independent team metrics: Each team’s performance is measured separately
• Specialized workflows: Tickets follow the appropriate processes for each team
• Clear ownership: No ambiguity about which team is responsible
• Preserved context: Complete history is maintained for seamless handoffs

​

Important considerations

• Ticket number changes: Customers will see a new ticket number (e.g., SUP-123 becomes SEC-456)
• Form compatibility: Field mapping may be required when teams use different forms
• SLA reset: New tickets start with the destination team’s SLA timeline

​

Impact on team operations

Understanding how moving tickets between teams affects different operational aspects is crucial for your organization.

​

SLA management

How it works:

• Original ticket archived with transfer details logged in activity
• New ticket starts fresh SLA clock
• Each team measured independently

Example:

• Support team receives SUP-122 at 9:00 AM (4-hour SLA)
• Archives SUP-122 at 11:00 AM (SLA paused)
• Activity log shows: “Transferred to Security team as SEC-980 by Agent John”
• Security team creates SEC-980 at 11:00 AM (8-hour SLA)
• Security has full 8 hours to resolve SEC-980
• SUP-122 and SEC-980 are linked as related tickets

Impact:

• ✅ Clean metrics separation between teams
• ✅ Each team measured on their actual work
• ✅ No cross-team SLA conflicts
• ⚠️ Customer may see extended total resolution time

​

Auto-responders

How it works:

• Original ticket keeps source team’s auto-responder
• New ticket gets destination team auto-responders
• Customer receives both auto-responders as the external communication channel remains the same

Example:

• SUP-122: Original ticket retains Support team’s auto-responder
• SEC-980: Security auto-responder welcomes customer with new expectations
• Customer receives Security team’s auto-responder message
• SUP-122 activity log records: “Transferred to Security team as SEC-980 by Agent John”

Impact:

• ✅ Clear separation of team communication styles
• ✅ Appropriate messaging for each team’s expertise
• ⚠️ Customer may receive multiple auto-responders

​

Customer satisfaction (CSAT)

How it works:

• Source team’s CSAT is cancelled upon ticket archival and will not be sent
• Only destination team receives CSAT measurement
• Each team’s metrics remain separate
• CSAT is measured only for the final resolving team

Example:

• SUP-122: CSAT cancelled upon archival (no survey sent)
• SEC-980: 3/5 stars (“Resolution took longer than expected”)
• Support team: No CSAT impact
• Security team: 3/5 added to team average

Impact:

• ✅ Clear accountability for final resolution
• ✅ Accurate team performance metrics
• ✅ No survey fatigue from multiple requests
• ⚠️ Source team’s contribution not measured
• ⚠️ Only final team’s performance captured

​

Workflows and automation

How it works:

• Original ticket completes source team workflows
• New ticket starts fresh with destination team workflows
• Both workflows run independently
• Migration triggers can coordinate between workflows

Example:

• SUP-122: Completes Support workflow (status: “Archived”)
• Activity log records: “Transferred to Security team as SEC-980 by Agent John”
• SEC-980: Starts Security workflow from beginning
• Support workflow: Triggers “ticket archival” automation
• Security workflow: Triggers “new incident” automation
• Move workflow: Coordinates data transfer and notifications
• Both tickets automatically linked as related tickets

Impact:

• ✅ Clean workflow execution for each team
• ✅ No conflicts between different team processes
• ✅ Appropriate automation for each team’s needs

​

Forms and fields management

Since forms and custom fields are configured at the team level, moving tickets between teams requires careful handling of field mapping and form selection.

​

Form selection when moving tickets

Process:

• Original ticket retains source team’s form and fields
• User selects destination team’s form for the new ticket
• System maps compatible fields automatically
• User reviews and adjusts field mappings
• New ticket created with destination team’s selected form
• Field values copied where compatible mappings exist
• Reference link maintained between tickets

Example:

• SUP-122: Keeps “General Support Request” form (archived)
• User selects “Security Incident” form for SEC-980
• System maps Priority → Severity, Description → Incident Details
• SEC-980: Created with “Security Incident” form and mapped data
• Original form data preserved in SUP-122 for reference
• Both tickets automatically linked as related tickets

​

Field mapping process

​

Field type compatibility

​

Data preservation strategies

​

Source-based policies for moving tickets

Different sources have different capabilities and restrictions for moving tickets between teams based on their technical constraints and business requirements.

​

Slack-based tickets

​

Communication handling when moving Slack tickets

How it works:

• Original ticket archived and disconnected from Slack thread
• New ticket created in destination team and connected to the Slack thread
• Customer messages in Slack are now captured in the new ticket
• Destination team receives all new customer messages in the new ticket
• Complete conversation history transferred to maintain context
• Both tickets automatically linked as related tickets

Customer experience:

• Continues messaging in the same Slack thread
• Messages are captured in the new ticket system
• Receives responses from destination team in same thread
• Seamless communication experience despite backend ticket change

Team experience:

• New ticket receives all ongoing Slack communications
• Complete historical messages from original ticket available for reference
• Destination team manages all new communications through new ticket
• Clean separation between old and new ticket workflows
• Access to full context from previous team interactions

Important considerations:

• Thread ownership transfer: Slack thread switches from original to new ticket
• Complete history transfer: All conversation history moves to the new ticket
• Notification routing: All new Slack notifications go to destination team
• Context preservation: Full thread context maintained for seamless handoff

​

Email-based tickets

​

Communication handling when moving email tickets

How it works:

• Original ticket archived and email thread disconnected
• New ticket created in destination team and connected to the email thread
• All new email replies are captured in the new ticket
• Destination team receives all new email messages
• Complete email history transferred to maintain context
• Both tickets automatically linked as related tickets

Team experience:

• New ticket receives all ongoing email communications
• Complete historical messages from original ticket available for reference
• Destination team manages all new communications through new ticket
• Clean separation between old and new ticket workflows
• Access to full context from previous team interactions

Important considerations:

• Thread ownership transfer: Email thread switches from original to new ticket
• Complete history transfer: All email conversation history moves to the new ticket
• Email routing: All new email replies go to destination team
• Context preservation: Full thread context maintained for seamless handoff

​

MS Teams-based tickets

​

Communication handling when moving MS Teams tickets

How it works:

• Original ticket archived and Teams thread disconnected
• New ticket created in destination team and connected to the Teams thread
• All new Teams messages are captured in the new ticket
• Destination team receives all new Teams messages
• Complete conversation history transferred to maintain context
• Both tickets automatically linked as related tickets

Team experience:

• New ticket receives all ongoing Teams communications
• Complete historical messages from original ticket available for reference
• Destination team manages all new communications through new ticket
• Clean separation between old and new ticket workflows
• Access to full context from previous team interactions

Important considerations:

• Thread ownership transfer: Teams thread switches from original to new ticket
• Complete history transfer: All Teams conversation history moves to the new ticket
• Message routing: All new Teams messages go to destination team
• Context preservation: Full thread context maintained for seamless handoff

​

Process flow

​

Moving tickets between teams flow

​

Communication ownership

​

External communication (customer-facing)

During the move:

• Ownership: Destination team takes immediate ownership
• Continuity: Customer sees seamless transition
• Branding: Destination team’s signature and branding applied

Historical messages:

• Preservation: All previous messages remain visible
• Attribution: Original team attribution maintained
• Context: Full conversation history available to destination team
• Search: All messages searchable by destination team

​

Internal communication (team-facing)

Private notes:

• Transfer: All private notes transferred to destination team
• Audit trail: Reason for move and timestamp recorded
• Collaboration: Option to maintain shared access for specific notes

Internal threads:

• Ownership: Destination team owns all internal discussions
• History: Previous internal conversations preserved
• Notifications: Internal notifications route to destination team

​

Example scenarios

​

Scenario 1: Support to security escalation

Context: A customer reports a potential security vulnerability through the general support channel.

​

Scenario 2: Moving ticket back to original team (Security to Support)

Context: After investigation, Security team determines the reported issue is not a security vulnerability but a product question, requiring the ticket to be moved back to the original Support team.

​

API reference

​

Moving tickets between teams

POST /v1/tickets/{id}/move

{
  "destinationTeamId": "team_security_001",
  "moveType": "NEW_TICKET",
  "reason": "Security vulnerability reported",

  "formConfiguration": {
    "destinationFormId": "form_security_incident",
    "fieldMappings": [
      {
        "sourceFieldId": "field_priority",
        "destinationFieldId": "field_severity",
        "mappingType": "DIRECT"
      },
      {
        "sourceFieldId": "field_description",
        "destinationFieldId": "field_incident_details",
        "mappingType": "DIRECT"
      }
    ],
    "unmappedFields": [
      {
        "fieldId": "field_customer_tier",
        "preserveInHistory": true
      }
    ],
    "requiredFieldValues": [
      {
        "fieldId": "field_threat_level",
        "value": "HIGH"
      }
    ]
  }
}

Response:

{
  "success": true,
  "moveId": "move_abc123",
  "status": "COMPLETED",
  "originalTicket": {
    "id": "ticket_123",
    "teamId": "team_support_001",
    "status": "ARCHIVED",
    "archivedAt": "2024-01-15T10:30:00Z"
  },
  "newTicket": {
    "id": "ticket_456",
    "teamId": "team_security_001",
    "createdAt": "2024-01-15T10:30:00Z",
    "createdBy": "agent_123"
  },
  "move": {
    "fromTeam": "team_support_001",
    "toTeam": "team_security_001",
    "type": "NEW_TICKET",
    "reason": "Security vulnerability reported",
    "completedAt": "2024-01-15T10:30:15Z"
  },
  "formMapping": {
    "fromForm": "form_general_support",
    "toForm": "form_security_incident",
    "fieldMappings": {
      "successful": [
        {
          "sourceField": "Priority",
          "destinationField": "Severity",
          "originalValue": "High",
          "mappedValue": "High"
        },
        {
          "sourceField": "Description",
          "destinationField": "Incident Details",
          "originalValue": "Customer reports suspicious activity",
          "mappedValue": "Customer reports suspicious activity"
        }
      ],
      "preserved": [
        {
          "field": "Customer Tier",
          "value": "Enterprise",
          "location": "original_ticket_history"
        }
      ],
      "required": [
        {
          "field": "Threat Level",
          "value": "HIGH",
          "source": "user_input"
        }
      ]
    }
  },
  "relatedTickets": {
    "originalTicketReference": "SUP-123",
    "newTicketReference": "SEC-980",
    "relationshipType": "MOVED_TO",
    "linkCreated": true,
    "canUnarchive": true
  },
  "activityLog": {
    "originalTicketActivity": {
      "action": "TICKET_TRANSFERRED",
      "details": "Transferred to Security team as SEC-980",
      "performedBy": "agent_123",
      "performedAt": "2024-01-15T10:30:00Z",
      "destinationTeam": "team_security_001",
      "newTicketId": "ticket_456"
    }
  }
}

Error Response:

{
  "success": false,
  "error": {
    "code": "MOVE_NOT_ALLOWED",
    "message": "Moving tickets from Support to Security team is not allowed for Slack-based tickets from private channels",
    "details": {
      "sourceType": "SLACK",
      "restriction": "PRIVATE_CHANNEL_POLICY",
      "allowedDestinations": ["team_support_001", "team_billing_001"],
      "moveType": "NEW_TICKET"
    }
  }
}

​

Best practices

​

Related resources