Connect ticket pipelines to release management in CrmLeaf

Configure the release pipeline structure

1. 1

   Enable Release Management for your engineering project.

2. 2

   Configure Release Stages. These are the gates a release passes through before production:

   Stage	Description	Exit Criteria
   Planning	Tasks being selected and assigned to this release	All selected tasks have owners and estimates
   In Development	Engineering sprint active; tasks being worked	All tasks in Done or moved to next release
   Code Freeze	No new code; only bug fixes for release-blocking issues	Zero open P1 tasks in this release
   QA & Staging	Release deployed to staging; QA testing active	QA sign-off from designated QA lead
   Ready for Release	All checks passed; awaiting publish approval	Product Manager approval
   Released	Published to production; clients notified	All linked tickets auto-closed

   Planning

   Description

   Tasks being selected and assigned to this release

   Exit Criteria

   All selected tasks have owners and estimates

   In Development

   Description

   Engineering sprint active; tasks being worked

   Exit Criteria

   All tasks in Done or moved to next release

   Code Freeze

   Description

   No new code; only bug fixes for release-blocking issues

   Exit Criteria

   Zero open P1 tasks in this release

   QA & Staging

   Description

   Release deployed to staging; QA testing active

   Exit Criteria

   QA sign-off from designated QA lead

   Ready for Release

   Description

   All checks passed; awaiting publish approval

   Exit Criteria

   Product Manager approval

   Released

   Description

   Published to production; clients notified

   Exit Criteria

   All linked tickets auto-closed

3. 3

   Configure Stage Gate Approvals: set who must approve the transition from QA & Staging to Ready for Release (typically QA Lead) and from Ready for Release to Released (typically Product Manager).

Create and populate a release

1. 1

   Click Create Release. Fill in:

   • Release name: use semantic versioning (e.g. v3.5.0) or date-based naming (2026-Q2-R1)
   • Target release date: the date you plan to publish to production
   • Release description: internal summary of the release theme (e.g. 'Performance improvements + 12 bug fixes')
   • Linked project: select the engineering sprint project
2. 2

   Add tasks to the release by navigating to the project backlog and selecting tasks → Assign to Release → [Release Name]. Tasks with linked tickets automatically bring their ticket references into the release.

3. 3

   Review the Linked Tickets panel on the release detail page. This shows every client ticket that will be resolved by this release.

4. 4

   Set the Release Visibility for clients: Internal Only (clients cannot see the release in their portal) or Announced (clients with linked tickets see the release in their portal with its target date). Announced releases set the expected resolution date for all linked tickets automatically.

Configure client release notifications

1. 1

   Enable Release Notifications. Configure three notification triggers:

   Trigger	When It Fires	Content
   Release announced	When a release moves to Announced stage	'Your issue [#X] is scheduled for resolution in [Release Name], targeted for [Date].'
   Release delayed	When target date changes on an Announced release	'We need to update you: [Release Name] has been rescheduled to [New Date].'
   Release published	When PM publishes the release to production	'Your issue [#X] has been resolved. It was included in [Release Name].'

   Release announced

   When It Fires

   When a release moves to Announced stage

   Content

   'Your issue [#X] is scheduled for resolution in [Release Name], targeted for [Date].'

   Release delayed

   When It Fires

   When target date changes on an Announced release

   Content

   'We need to update you: [Release Name] has been rescheduled to [New Date].'

   Release published

   When It Fires

   When PM publishes the release to production

   Content

   'Your issue [#X] has been resolved. It was included in [Release Name].'

2. 2

   Configure the Notification Template for each trigger. Use merge fields to personalise: {{client_name}}, {{ticket_id}}, {{ticket_summary}}, {{release_name}}, {{release_date}}, {{release_version}}.

3. 3

   Under Notification Audience, set: send to the Primary Contact on the client account plus any additional contacts who are cc'd on the original ticket. Do not send release notifications to contacts who had no open tickets in the release - they are noise to anyone not affected.

4. 4

   Enable Release Notes Generation: when a release is published, CrmLeaf automatically generates a release notes document containing all resolved tickets, grouped by category. The release notes are attached to the Published notification email and available in the client portal.

Manage the release lifecycle

Once a release is created and populated, the product manager's workflow is:

1. 1

   Daily: check the Release Progress dashboard. This shows task completion percentage per release, any tasks that have moved to blocked status, and the SLA at-risk count.

2. 2

   SLA at-risk response: if tickets are at risk of breaching before the release date, the PM has three options: move the task to an expedited release, negotiate a resolution SLA extension with the client, or escalate to engineering for a hotfix outside the sprint cycle.

3. 3

   Code freeze gate: advance the release to Code Freeze when all planned tasks are Done. Review any remaining In Progress tasks - either move them to the next release or escalate to get them finished.

4. 4

   QA gate: assign QA Lead as the approver. They test the staging deployment and approve the gate. Any QA-discovered bugs are either fixed (new tasks added) or documented as known issues for the next release.

5. 5

   Publish: PM approves the Ready for Release gate. CrmLeaf publishes the release: all linked tickets auto-close, all affected clients receive their personalised notification, release notes are generated and distributed.

Analytics: ticket volume as sprint priority input

1. 1

   Enable the Engineering Impact Dashboard. This surfaces ticket data in a format useful for sprint planning:

   Report	What It Shows	Sprint Planning Use
   Top 10 bug categories by ticket volume	Which feature areas generate the most bug reports	Prioritise fixes in highest-volume areas
   Client impact score per open task	Ticket count × client tier weight per unresolved task	Objective priority ranking for backlog grooming
   Repeat reporter analysis	Clients submitting 3+ tickets on the same issue	Flag for dedicated engineering investigation
   SLA at-risk by release	Tickets at risk of breach before their linked release date	Identify which tasks to expedite
   Resolution time by ticket type	Average days from ticket open to task release	Benchmark for setting client expectations

   Top 10 bug categories by ticket volume

   What It Shows

   Which feature areas generate the most bug reports

   Sprint Planning Use

   Prioritise fixes in highest-volume areas

   Client impact score per open task

   What It Shows

   Ticket count × client tier weight per unresolved task

   Sprint Planning Use

   Objective priority ranking for backlog grooming

   Repeat reporter analysis

   What It Shows

   Clients submitting 3+ tickets on the same issue

   Sprint Planning Use

   Flag for dedicated engineering investigation

   SLA at-risk by release

   What It Shows

   Tickets at risk of breach before their linked release date

   Sprint Planning Use

   Identify which tasks to expedite

   Resolution time by ticket type

   What It Shows

   Average days from ticket open to task release

   Sprint Planning Use

   Benchmark for setting client expectations

2. 2

   Share the Engineering Impact Dashboard with the engineering lead before each sprint planning session. The objective data from client ticket volume should inform but not fully dictate engineering priority - some low-ticket-volume bugs may be architecturally critical.