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

1

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
2

User review

Migration interface shows:

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

Manual adjustment

User can:

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

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

​
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.

1

Initial ticket creation

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

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
3

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.

1

Return preparation

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

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
3

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

1

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
2

Team preparation

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

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
4

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