Parent-child ticket relationships in Freshdesk are powerful and easy to abuse. Used right, they coordinate cross-team work on a single customer issue. Used wrong, they fragment SLA reporting and confuse customers about who owns what.
When parent-child fits
The pattern works when:
- One customer-facing issue requires work in multiple teams (network, billing, hardware).
- Each team needs its own SLA and assignment.
- Updates on child progress should not flood the customer thread.
The parent ticket stays customer-facing. Children are internal coordination units. The customer never sees child tickets unless you explicitly link them in a reply.
When to use linked tickets instead
Linked tickets (a softer relationship) fit when:
- Two unrelated requests reference the same root cause.
- You want to track a connection without enforcing a hierarchy.
- A customer files duplicate tickets that need to be merged later.
Linked tickets do not roll up status or close together. Parent-child does both, with the right configuration.
Auto-close on child completion
Configure: parent closes when all children are closed. This requires a workflow on the parent ticket that watches child status. Without it, parents stay open with no agent attention while all the work is done.
The workflow trigger: Child ticket status changes to Closed AND no other child ticket is open. Action: close parent and notify customer with a templated message summarizing all child resolutions.
SLA traps
A parent ticket with five children running in parallel inherits its own SLA. The parent SLA does not pause while children work. If the parent SLA is 24 hours and all children take 23 hours, the parent breaches at the same moment all children resolve.
Two fixes:
- Set the parent SLA based on the longest expected child duration plus buffer.
- Pause the parent SLA when any child is open via a workflow that sets the parent to “Waiting on third party” status.
The pause approach is cleaner because it survives variable child counts.
Visibility for the customer
Customers do not see children by default and should not. The customer wants one update on one ticket. Configure agent replies on children to not mirror to the parent automatically; the parent owner curates updates.
For complex projects (a 30-day implementation), expose a customer-facing project status page that pulls from a parent ticket custom field. Children stay internal; the customer sees a summary.
Reporting
Standard ticket reports count parents and children equally, which double-counts work for projects. Build a separate report that counts parents only and reports time-to-resolution at the parent level. Use a custom field is_parent set by workflow on creation to filter cleanly.
Bulk creation
When the same project repeats (onboarding new accounts, migrations), build a child-ticket template and trigger creation via a workflow on the parent. The workflow creates the children with the right group, SLA, and description in one shot.
Closing children when the parent closes
Configurable per workflow. Default is yes. If a parent closes (customer satisfied or canceled), all open children close as well. This prevents orphan internal work continuing after the customer left.
What to do this week
Find the three most common parent-child use cases your team handles. Build child templates for each and document the close-cascade behavior. Confirm SLA pause is set on the parent.
