Events & triggers
Understanding events and triggers in the workflow system
A trigger is the foundation of workflow automation in the Thena platform. It consists of two key components: an event and filters. While events represent what happened, triggers allow you to specify exactly when a workflow should execute based on those events.
Understanding triggers
Core concept
A trigger is a combination of an event and optional filters. Events tell us what happened (e.g., “ticket created”), while filters let us specify precise conditions about when we care about that event (e.g., “only when the ticket priority is high”).
Event types
System events
• Ticket events: Created, updated, status changed
• User events: Created, updated, permissions changed
• Team events: Created, members changed
• Account events: Created, updated, status changed
Integration events
• Slack events: Message sent, channel created
• Email events: Received, sent, bounced
• Custom app events: Any app-specific events
• Scheduled events: Time-based triggers
Event anatomy
An event in the Thena Platform consists of several key components that define its structure and behavior.
Key components
Core properties
• uid: Unique identifier for the event
• eventName: Human-readable name
• eventType: Machine-readable type (e.g., ticket:updated
)
• source: Origin of the event
• description: Human-readable description
Schema structure
• message: Core event data including actor and payload
• messageAttributes: Context and metadata about the event
• required fields: Mandatory data points
• properties: Data type definitions and validations
Event data structure
Events follow a consistent structure that enables:
- Rich context through nested properties
- Type safety with JSON schema validation
- Clear audit trail with actor and timestamp information
- Flexible data access through dot notation in filters
Here’s a comprehensive example of a ticket update event:
Trigger components
Event definition
Name | Type | Options | Comments |
---|---|---|---|
Event Name | string | Required, Format: app:event | Unique event identifier |
Event Schema | object | Required | JSON Schema of event data |
Event Data | object | Required | Actual event payload |
Source | string | Required | Event origin identifier |
Timestamp | datetime | Required | Event occurrence time |
Filter operators
Filters in triggers allow you to specify precise conditions for when a workflow should execute. The platform supports a comprehensive set of operators:
Comparison operators
Operator | Description | Example |
---|---|---|
~eq | Equals | {"priority": {"~eq": "high"}} |
~neq | Not equals | {"status": {"~neq": "closed"}} |
~gt | Greater than | {"value": {"~gt": 100}} |
~gte | Greater than or equal | {"age": {"~gte": 18}} |
~lt | Less than | {"count": {"~lt": 5}} |
~lte | Less than or equal | {"score": {"~lte": 10}} |
Collection operators
Operator | Description | Example |
---|---|---|
~in | In array | {"status": {"~in": ["open", "pending"]}} |
~nin | Not in array | {"type": {"~nin": ["internal", "test"]}} |
String operators
Operator | Description | Example |
---|---|---|
~regex | Matches regex | {"email": {"~regex": ".*@company\\.com"}} |
~nregex | Does not match regex | {"url": {"~nregex": ".*\\.test\\.com"}} |
~starts | Starts with | {"name": {"~starts": "Test"}} |
~nstarts | Does not start with | {"ref": {"~nstarts": "DRAFT"}} |
~ends | Ends with | {"email": {"~ends": "@thena.ai"}} |
~nends | Does not end with | {"path": {"~nends": ".tmp"}} |
~contains | Contains | {"description": {"~contains": "urgent"}} |
~ncontains | Does not contain | {"title": {"~ncontains": "test"}} |
Special operators
Operator | Description | Example |
---|---|---|
~isnull | Is null | {"assignee": {"~isnull": true}} |
~isempty | Is empty | {"tags": {"~isempty": true}} |
Logical operators
Operator | Description | Example |
---|---|---|
~and | All conditions must match | {"~and": [{"status": {"~eq": "open"}}, {"priority": {"~eq": "high"}}]} |
~or | Any condition must match | {"~or": [{"type": {"~eq": "bug"}}, {"priority": {"~eq": "high"}}]} |
Filter operators can be combined to create complex conditions. The platform evaluates them in a deterministic order, with logical operators (~and, ~or) being evaluated last.
Example trigger
This example demonstrates:
- Using context variables with dot notation to access nested properties
- Combining multiple logical operators
- Checking for specific team, status, and comment properties
- Using various comparison and special operators
Platform events reference
Events are real-time notifications that your application can listen to when specific actions occur in the Thena platform. Each event contains metadata about when and where it was triggered, along with relevant payload data.
Event structure
All events in the Thena platform follow a consistent base structure:
Available events
Organization events
org:created
- When a new organization is createdorg:updated
- When organization details are updatedorg:deleted
- When an organization is deletedorg:settings:updated
- When organization settings are modified
Team events
team:created
- When a new team is createdteam:updated
- When team details are updatedteam:deleted
- When a team is deletedteam:member:added
- When a member is added to a teamteam:member:removed
- When a member is removed from a team
User events
user:created
- When a new user is createduser:updated
- When user details are updateduser:deleted
- When a user is deleteduser:status:changed
- When a user’s status changesuser:role:changed
- When a user’s role is modifieduser:login
- When a user logs inuser:logout
- When a user logs out
Ticket events
ticket:created
- When a new ticket is createdticket:updated
- When ticket details are updatedticket:deleted
- When a ticket is deletedticket:status:changed
- When a ticket’s status changesticket:assigned
- When a ticket is assignedticket:unassigned
- When a ticket is unassignedticket:priority:changed
- When a ticket’s priority changesticket:comment:added
- When a comment is added to a ticketticket:comment:updated
- When a comment is updatedticket:comment:deleted
- When a comment is deletedticket:reaction:added
- When a reaction is added to a ticketticket:reaction:removed
- When a reaction is removed from a ticketticket:comment:reaction:added
- When a reaction is added to a commentticket:comment:reaction:removed
- When a reaction is removed from a comment
Account events
account:created
- When a new account is createdaccount:updated
- When account details are updatedaccount:deleted
- When an account is deletedaccount:status:changed
- When an account’s status changes
Customer events
customer:created
- When a new customer is createdcustomer:updated
- When customer details are updatedcustomer:deleted
- When a customer is deletedcustomer:merged
- When customer records are merged
Custom field events
custom_field:created
- When a new custom field is createdcustom_field:updated
- When a custom field is updatedcustom_field:deleted
- When a custom field is deletedcustom_field:value:changed
- When a custom field value changes
Form events
form:created
- When a new form is createdform:updated
- When a form is updatedform:deleted
- When a form is deletedform:submission:created
- When a form submission is receivedform:submission:updated
- When a form submission is updated
SLA events
sla:created
- When a new SLA policy is createdsla:updated
- When an SLA policy is updatedsla:deleted
- When an SLA policy is deletedsla:breach:warning
- When an SLA is about to breachsla:breach:occurred
- When an SLA breach occurs
Workflow events
workflow:created
- When a new workflow is createdworkflow:updated
- When a workflow is updatedworkflow:deleted
- When a workflow is deletedworkflow:executed
- When a workflow starts executionworkflow:step:completed
- When a workflow step is completedworkflow:completed
- When a workflow execution completes
CSAT events
csat:survey:sent
- When a CSAT survey is sentcsat:response:received
- When a CSAT response is receivedcsat:feedback:updated
- When CSAT feedback is updated
App events
app:installed
- When an app is installed in a workspaceapp:uninstalled
- When an app is uninstalled from a workspaceapp:reinstalled
- When an app is reinstalled in a workspaceapp:mentioned
- When an app is mentioned in a conversationapp:settings:updated
- When app settings are modified
Source integration events
Slack events
source:slack:message:received
- When a message is received from Slacksource:slack:thread:created
- When a new thread is created in Slacksource:slack:reaction:added
- When a reaction is added in Slack
MS Teams events
source:msteams:message:received
- When a message is received from MS Teamssource:msteams:thread:created
- When a new thread is created in MS Teamssource:msteams:reaction:added
- When a reaction is added in MS Teams
Email events
source:email:received
- When an email is receivedsource:email:bounced
- When an email bouncessource:email:replied
- When an email is replied to
Widget events
source:widget:opened
- When the widget is openedsource:widget:message:sent
- When a message is sent via widgetsource:widget:closed
- When the widget is closed
Event delivery and retries
Events are delivered in real-time with automatic retries on failure:
- First attempt: Immediate delivery
- Second attempt: After 3 minutes
- Final attempt: After 5 minutes
Your webhook endpoint must respond within 3 seconds, or the request will time out and trigger the retry mechanism.
Design your event handlers to be idempotent as you may receive the same event multiple times during retries.
Best practices for event consumers
Handling events reliably
- Implement idempotency checks: Store processed event IDs to avoid duplicate processing during retries
- Use event timestamps: Process events in chronological order using the
timestamp
field - Validate event data: Always validate the event payload before processing to handle schema changes gracefully
Performance optimization
- Process asynchronously: Handle events in background workers to avoid blocking your main application
- Batch related operations: Group related database updates or API calls for better performance
- Set reasonable timeouts: Acknowledge webhooks within 3 seconds and process heavy tasks asynchronously
- Queue long-running tasks: If processing takes longer than 3 seconds, acknowledge the webhook and process in background
Error handling
- Log processing errors: Include event ID and type in error logs for easier debugging
- Implement dead letter queues: Store failed events separately for manual review
- Monitor processing delays: Set up alerts for event processing backlogs
Security
- Validate webhook signatures: Use the provided signature to verify event authenticity
- Secure API keys: Store webhook secret keys in secure environment variables
- Filter by event types: Subscribe only to events your application needs
Testing
- Use the event simulator: Test your handlers with simulated events before going live
- Verify retry handling: Test your idempotency logic with duplicate events
- Monitor event processing: Track success rates and processing times in production
Remember to version your event handlers to handle potential schema changes in future platform updates.