Feature request: Expanded trigger and automation condition/control capabilities (User Segments, Ticket Origin Attribution, and CC Management)

Summary

Enhance Zendesk Support triggers and automations to provide:

1. The ability to dynamically evaluate Help Centre User Segment membership as a condition
2. Clear and granular conditions to distinguish between Requester, Submitter, Agent creator, and System/API-created tickets
3. Full conditional control over CC identification, addition, and removal

These enhancements would materially improve notification accuracy, SLA precision, compliance control, and customer experience.

1. Help Centre User Segments as Trigger Conditions

Problem

Help Centre User Segments are a powerful mechanism for controlling content visibility in Guide, but they cannot currently be used as dynamic conditions within Support triggers or automations.

There is no way to:

• Evaluate whether a requester is in a specific User Segment
• Use segment membership as logic in notification workflows
• Select segments from a dropdown list within trigger conditions

This creates a disconnect between:

• Knowledge visibility strategy
• Support workflow logic

Proposed Solution

Add a trigger/automation condition:

Requester is in User Segment → [Selectable Segment(s)]

With capabilities to:

• Dynamically evaluate membership
• Select one or multiple segments
• Use both positive and negative logic (is / is not in segment)

Use Case

Segment-based customer groupings (e.g. Partner, Regulated Client, Premium Tier) should be usable to:

• Deliver different notification wording
• Adjust SLA logic
• Control escalation workflows

Currently, organisations must duplicate logic via custom fields or external systems, creating governance risk and duplication.

Impact

• Stronger alignment between Guide segmentation and Support workflows
• Reduced reliance on custom workaround fields
• More scalable enterprise-grade workflow governance

2. Expanded Ticket Origin Attribution in Triggers

Problem

Zendesk currently limits trigger conditions primarily to the Requester and provides insufficient granularity for distinguishing:

• Submitter (ticket creator) vs Requester
• Full Agent manually creating a ticket
• Light Agent forwarding/creating a ticket
• System/Automation/API-created tickets
• Email-forwarded tickets where creator differs from requester

For organisations that frequently create tickets on behalf of customers, this creates significant workflow limitations.

Primary impact:

• Notification wording must differ depending on who created the ticket
• Current condition sets are insufficiently granular

Secondary benefit:

• SLA policies could be more precisely applied

Proposed Solution

Expand trigger/automation condition sets to include:

• Ticket Created By Type
  • End User
  • Full Agent
  • Light Agent
  • Automation
  • API
  • System
  • Forwarded Email
• Explicit conditions for:
  • Submitter role
  • Submitter vs Requester mismatch
  • Agent-created-on-behalf-of scenarios

Example condition:

Ticket creator role is Full Agent
AND Requester role is End User

This would enable deterministic workflow control.

Use Case

If:

• A full agent manually creates a ticket and sets an end user as the requester
• A light agent forwards an email on behalf of a customer
• A ticket is generated by API or automation

Then:

• Confirmation wording must differ
• Autoresponders may need suppression
• SLA policies may differ

Currently, this requires brittle workarounds or cannot be reliably achieved.

Impact

• More accurate and context-aware notifications
• Reduced customer confusion
• Improved SLA governance
• Better enterprise workflow transparency

3. Conditional CC Identification, Addition, and Removal

Problem

Triggers can add CCs in limited ways but cannot:

• Reliably detect whether a specific user is already CC’d
• Remove specific CCs conditionally
• Dynamically manage CC lists based on compliance or workflow logic

This creates operational and compliance challenges.

Example scenario:
A customer emails both the support team and a regulator in a single message (as required by regulation).

Current issue:

• The regulator receives Zendesk autoresponses
• The regulator continues receiving agent updates
• Agents must manually remove them
• Regulators have complained about unnecessary email noise

There is no robust trigger-based method to detect and remove a specific CC address once the ticket is created.

Proposed Solution

Enhance trigger/automation capabilities to:

Add conditions:

• CC list contains [specific user/email]
• CC list does not contain [specific user/email]

Add actions:

• Add specific CC
• Remove specific CC
• Remove CC if condition met

Allow this to be used in both triggers and automations.

Use Cases

• Regulatory compliance communications
• Contractual stakeholder visibility
• Partner-based notifications
• Suppression of autoreplies to third-party recipients
• Operational routing control

Impact

• Improved compliance governance
• Reduced email noise for regulators and partners
• Improved customer experience
• Reduced manual intervention and agent error

Business Context

Suite Enterprise customers require deterministic workflow control aligned with:

• Regulatory obligations
• Contractual requirements
• Complex multi-party communications
• Enterprise-grade notification logic

Current limitations require API-based workarounds or manual processes for functionality that logically belongs within triggers and automations.

Current Workarounds

• Custom fields duplicating segment logic
• External reporting tools (e.g. Power BI) to infer creation context
• Manual CC removal
• Suppression rules that are brittle or incomplete
• API middleware to retrofit missing logic

These add operational overhead and governance risk.

Overall Value

These enhancements would:

• Close the gap between Guide segmentation and Support workflows
• Provide enterprise-grade workflow determinism
• Reduce integration complexity
• Improve customer and partner experience
• Strengthen compliance and SLA control