Moving tickets between teams

Policies for moving tickets between teams are based on source of the ticket and team combination to ensure proper governance and maintain service quality standards.

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

Automatic mapping

System attempts to map fields based on:

Field names (exact match)
Field types (compatible types)
Common field patterns (priority/severity, description/details)
Previous mapping configurations

User review

Migration interface shows:

Automatically mapped fields
Unmapped source fields
Available destination fields
Mapping suggestions based on field types

Manual adjustment

User can:

Accept automatic mappings
Override suggested mappings
Map additional fields manually
Choose to preserve unmapped data in history

Validation

System validates:

Required fields in destination form are populated
Field value compatibility (text to text, number to number)
Field constraints and validation rules
Data format requirements

Field type compatibility

Compatible mappings

• Text → Text
• Number → Number
• Date → Date
• Single Select → Single Select (if options match)
• Multi Select → Multi Select (if options match)
• Boolean → Boolean

Incompatible mappings

• Text → Number (unless parseable)
• Single Select → Multi Select
• Date → Text (format issues)
• Custom field types with different schemas
• Fields with different validation rules

Data preservation strategies

Mapped fields

Unmapped fields

Required fields

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

Both source and destination teams must have Slack configured and access to the same Slack workspace for moving tickets to be possible.

Moving tickets allowed

• Internal help desk
• Shared customer channels
• External channels
• Guest channels

Moving tickets restricted

• Cross-Slack-workspace scenarios
• Archived conversations
• Deleted channels

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

Both source and destination teams must have email configured and access to the same email domain for moving tickets to be possible.

Moving tickets allowed

• Standard support emails
• Forwarded conversations
• CC/BCC scenarios (multiple team members are copied)

Moving tickets restricted

• Personal email addresses
• Cross domain 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

Both source and destination teams must have MS Teams configured and access to the same MS Teams tenant for moving tickets to be possible.

Moving tickets allowed

• Standard channels
• Shared channels
• Private channels

Moving tickets restricted

• Private chats
• Guest user conversations
• Cross-tenant scenarios

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.

Initial ticket creation

Ticket created in Support team (default for email source)
Support agent recognizes security implications
Agent initiates move to Security team

Moving process

System validates: Email source allows moving to Security team
Move approved automatically (using default form with no custom fields)
New ticket created in Security team with all context

After the move

Security team’s SLA and response templates applied
All future communication handled by Security team

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.

Return preparation

Security team documents findings
Prepares handoff notes for Support team
Updates ticket classification and priority

Return process

Original ticket SUP-122 is unarchived and reactivated
SEC-980 is archived
Activity log records: “Transferred back to Support team, SUP-122 unarchived by Security Agent Sarah”
Support team’s processes and workflows are reapplied
SLA resumes from where it was paused (2 hours remaining from original 4-hour SLA)
Security team’s notes and findings are preserved in ticket history

Related ticket chain

Two tickets now exist: SUP-122 (original, reactivated), SEC-980 (archived)
Both tickets are automatically linked as related tickets
Complete audit trail maintained across the entire customer journey
Each team’s work and timeline clearly separated and measurable
Original ticket maintains its ticket number and customer communication continuity

When tickets are moved back to the original team, the original archived ticket is unarchived and reactivated rather than creating a new ticket. This maintains ticket number continuity for the customer and allows the SLA to resume from where it was paused. The SLA timer continues from the remaining time when the ticket was originally transferred, ensuring accurate measurement of the original team’s total resolution time. All tickets in the chain remain linked as related tickets for complete traceability.

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

Understanding policies for moving tickets

Familiarize teams with source-based restrictions for moving tickets
Understand which ticket types can be moved between teams
Know the limitations for each communication channel

Team preparation

Train teams on processes and tools for moving tickets
Establish clear handoff procedures and documentation

Form and field management

Design compatible forms across teams where possible
Establish field naming conventions for easier mapping
Document field mapping strategies for common moves
Train teams on field mapping and validation processes

Customer communication

Provide consistent branding across team transitions
Maintain transparency about why tickets are moved

Teams management

Configure teams and their capabilities

Routing rules

Set up automatic ticket routing

SLA management

Configure service level agreements

Workflow automation

Automate processes for moving tickets

Introduction

Core concepts

Apps framework

Sources

​How moving tickets works

​The process

​Benefits

​Important considerations

​Impact on team operations

​SLA management

​Auto-responders

​Customer satisfaction (CSAT)

​Workflows and automation

​Forms and fields management

​Form selection when moving tickets

​Field mapping process

​Field type compatibility

Compatible mappings

Incompatible mappings

​Data preservation strategies

​Source-based policies for moving tickets

​Slack-based tickets

Moving tickets allowed

Moving tickets restricted

​Communication handling when moving Slack tickets

​Email-based tickets

Moving tickets allowed

Moving tickets restricted

​Communication handling when moving email tickets

​MS Teams-based tickets

Moving tickets allowed

Moving tickets restricted

​Communication handling when moving MS Teams tickets

​Process flow

​Moving tickets between teams flow

​Communication ownership

​External communication (customer-facing)

​Internal communication (team-facing)

​Example scenarios

​Scenario 1: Support to security escalation

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

​API reference

​Moving tickets between teams

​Best practices

​Related resources

Teams management

Routing rules

SLA management

Workflow automation

How moving tickets works

The process

Benefits

Important considerations

Impact on team operations

SLA management

Auto-responders

Customer satisfaction (CSAT)

Workflows and automation

Forms and fields management

Form selection when moving tickets

Field mapping process

Field type compatibility

Data preservation strategies

Source-based policies for moving tickets

Slack-based tickets

Communication handling when moving Slack tickets

Email-based tickets

Communication handling when moving email tickets

MS Teams-based tickets

Communication handling when moving MS Teams tickets

Process flow

Moving tickets between teams flow

Communication ownership

External communication (customer-facing)

Internal communication (team-facing)

Example scenarios

Scenario 1: Support to security escalation

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

API reference

Moving tickets between teams

Best practices

Related resources