Requests, Tickets and Tasks
Understanding the core concepts of ClearFeed's workflow
ClearFeed's workflow is built on three core concepts that work together:
Request → Ticket → Task
Requests - Internal tracking of customer inquiries
Tickets - Formal, customer-facing support cases
Tasks - Work items escalated to specialized teams
What is a Request?
A Request is any inquiry tracked internally in ClearFeed, regardless of where it comes from.
Key Characteristics
Internal only - Not visible to customers
No public ID - Only your team sees the request number
Private status - Status changes are visible only to responders
Universal inbox - All inquiries start as requests
Sources
Requests can be created from:
Slack channel messages
Direct messages to ClearFeed app
Emails to support address
Web chat conversations
Customer portal submissions
API calls
Request Fields
Every request includes:
Author (who created it)
Title (AI-generated or manual)
Summary (AI-generated)
Status (Open, In Progress, Pending, Solved, Closed)
Assignee (responder responsible)
Priority (Urgent, High, Normal, Low)
Created time
Last message time
Learn more about creating requests →
What is a Ticket?
A Ticket is a formal, customer-visible support case converted from a request.
Key Characteristics
Customer-visible - Customers can see the ticket ID and status
Public tracking - ID and status are shared with the requester
Formal record - Official support case for tracking and SLAs
Same fields as requests - All request information is preserved
Difference from Requests
Visibility
Internal only
Customer-facing
ID
Private
Public (e.g., CF-1234)
Status
Private
Shared with requestor
Types of Tickets
ClearFeed Tickets
Managed within ClearFeed
Native ticket IDs (e.g., CF-1234)
Visible in Slack and Customer Portal
External Tickets
Created in external systems (Zendesk, Jira, Salesforce, etc.)
External ticket IDs (e.g., ZEN-5678, JIRA-123)
Synced bidirectionally between systems
Learn more about creating/linking tickets →
What is a Task?
A Task is a work item escalated from a request or ticket to specialized teams (engineering, product, etc.) while maintaining the support context.
Key Characteristics
Work escalation - Moves technical work to engineering/project systems
SLA preservation - Original request/ticket SLA continues tracking
Linked context - Task remains connected to the customer request
System integration - Created in Jira, Linear, Asana, GitHub, ClickUp, etc.
Blocker Tasks
A special type of task that:
Prevents the ticket from being closed
Marks critical dependencies
Ensures work is completed before resolution
Task Visibility
Tasks can be configured with different visibility levels:
Full transparency - Task link and updates visible to customers
Link only - Task ID shared without detailed updates
Internal only - No customer visibility
Learn more about creating tasks →
Relationship Between Concepts
Customer Question
↓
Request (Created automatically)
↓
Ticket (Converted when formalization needed)
↓
Task (Escalated when specialized work required)Example Flow:
Customer posts in Slack: "API returning errors"
Request created automatically (private, internal tracking)
Agent converts to Ticket #CF-1234 (customer sees ID and status)
Agent escalates to Task JIRA-567 (engineering investigates)
Task marked as blocker (ticket can't close until bug fixed)
Engineering completes task → Ticket can be resolved
Related Documentation
Creating Requests - How requests are created
Creating Tickets - How to convert requests to tickets
Creating Tasks - How to escalate to engineering
Collections - Configure request/ticket behavior
SLA Management - Set up service level agreements
Custom Fields - Add fields to requests/tickets
Last updated