This is a sample comment
", "contentMarkdown": "This is a sample comment", "commentType": "comment", "commentVisibility": "public", "author": { "id": "USER123456", "name": "Sample User", "email": "user@example.com", "avatarUrl": "https://example.com/avatar.jpg" }, "teamId": "TEAM123456", "createdAt": "2024-01-01T12:00:00.000Z", "updatedAt": "2024-01-01T12:00:00.000Z" }, "ticket": { "id": "TICKET123456", "title": "Sample support request" } }, "eventId": "EVENT123456", "timestamp": "1704110400000" }, "xWebhookEvent": true } ``` ## Scopes The `scopes` section defines the permissions your app needs to function. Each scope grants access to specific Thena APIs and features. ### Scopes structure ```typescript theme={null} interface AppScopes { required: string[]; optional?: string[]; } ``` ### Available scopes #### Contact scopes * `contacts:read` - View contact information * `contacts:write` - Create and update contacts * `contacts:delete` - Delete contacts * `contacts.custom_fields:read` - View contact custom fields * `contacts.custom_fields:write` - Create and update contact custom fields #### Accounts scopes * `companies:read` - View company information * `companies:write` - Create and update companies * `companies:delete` - Delete companies * `companies.custom_fields:read` - View company custom fields * `companies.custom_fields:write` - Create and update company custom fields #### Conversation scopes * `conversations:read` - View conversations * `conversations:write` - Send and reply to messages * `conversations:delete` - Delete conversations * `conversations.attachments:read` - View conversation attachments * `conversations.attachments:write` - Add attachments to conversations #### User scopes * `users:read` - View user information * `users.preferences:read` - View user preferences * `users.preferences:write` - Update user preferences #### Organization scopes * `workspace:read` - View workspace settings * `workspace.members:read` - View workspace members * `workspace.teams:read` - View workspace teams ### Scopes example ```json theme={null} { "scopes": { "required": [ "contacts:read", "contacts:write", "companies:read", "deals:read" ], "optional": [ "contacts.custom_fields:write", "companies.custom_fields:write", "analytics:read", "analytics.reports:read" ] } } ``` ## Metadata The `metadata` section provides additional information about your app that helps users understand its capabilities and pricing. ### Metadata structure ```typescript theme={null} interface AppMetadata { title: string; rating?: number; pricing?: { yearly?: number; monthly?: number; }; category: string; capabilities: string[]; } ``` ### Metadata fields #### Title A concise title that describes your app's main function: ```json theme={null} { "title": "CRM & Marketing Integration" } ``` #### Rating Optional rating for your app (0-5): ```json theme={null} { "rating": 4.8 } ``` #### Pricing Define your app's pricing structure (in cents): ```json theme={null} { "pricing": { "yearly": 4990, // $49.90/year "monthly": 499 // $4.99/month } } ``` #### Category The primary category for your app: ```json theme={null} { "category": "crm_integration" } ``` Available categories: * `crm_integration` * `productivity` * `communication` * `analytics` * `automation` * `custom` #### Capabilities List of key features your app provides: ```json theme={null} { "capabilities": [ "Contact Management", "Company Sync", "Deal Pipeline", "Ticket Management", "Email Integration", "Marketing Automation" ] } ``` ## Integration The `integration` section defines how your app integrates with Thena, including webhook endpoints and entry points. ### Integration structure ```typescript theme={null} interface IntegrationConfig { webhooks: { events: string; installations: string; }; entry_points: { main: string; configuration?: string; oauth_redirect?: string; }; interactivity?: { request_url?: string; message_menu_option_url?: string; }; } ``` ### Webhooks Configure endpoints where Thena will send events and installation notifications: ```json theme={null} { "webhooks": { "events": "https://your-app.com/webhook/events", "installations": "https://your-app.com/webhook/installation" } } ``` #### Events webhook The `events` webhook receives all events your app subscribes to: ```json theme={null} { "event": "contact.created", "payload": { "id": "contact-123", "data": { "email": "user@example.com", "name": "John Doe" } } } ``` #### Installation webhook The `installations` webhook receives notifications when your app is installed or uninstalled: ```json theme={null} { "event": "app.installed", "payload": { "installation_id": "inst-123", "bot_token": "bot-token-xyz", "workspace_id": "workspace-123" } } ``` ### Entry points Define URLs for different parts of your app's interface: ```json theme={null} { "entry_points": { "main": "https://your-app.com/app", "configuration": "https://your-app.com/config", "oauth_redirect": "https://your-app.com/oauth/callback" } } ``` ## External select configuration External select configuration allows you to dynamically fetch options for select fields from your app's API endpoint. ### External select structure ```json theme={null} { "configuration": { "fields": [ { "type": "external_select", "key": "project", "label": "Project", "description": "Select a project", "required": true, "endpoint": "/api/projects" } ] } } ``` ### Request format When a user interacts with an external select field, Thena will make a GET request: ``` GET {your_app_url}{endpoint}?search={search_term} ``` ### Response format Your endpoint should return: ```json theme={null} { "options": [ { "value": "proj-123", "label": "Project A" }, { "value": "proj-456", "label": "Project B" } ] } ``` ## Activities Activities define HTTP-based operations your app can perform. Each activity represents an API endpoint that can be called by Thena. ### Activity structure ```typescript theme={null} interface Activity { name: string; description: string; http_config: { headers: RecordThis is a sample comment
", "contentMarkdown": "This is a sample comment", "commentType": "comment", "commentVisibility": "public", "author": { "id": "USER123456", "name": "Sample User", "email": "user@example.com", "avatarUrl": "https://example.com/avatar.jpg" }, "teamId": "TEAM123456", "createdAt": "2024-01-01T12:00:00.000Z", "updatedAt": "2024-01-01T12:00:00.000Z" }, "ticket": { "id": "TICKET123456", "title": "Sample support request" } }, "eventId": "EVENT123456", "timestamp": "1704110400000" }, "xWebhookEvent": true } ``` For a complete list of available events and their payloads, see our [platform events documentation](/platform/platform-events). ## Security model The Apps framework uses a token-based security model: 1. Installation security * Secure bot token generation * Workspace-scoped access 2. Request authentication * Token validation on each request * Request signing * Secure payload transmission 3. Data access control * Resource-level permissions * User context validation * Data encryption in transit ## Building blocks ### Events Events let you respond to changes in Thena. See our [platform events documentation](/platform/platform-events) for a complete list of available events. ```typescript theme={null} // Example event subscription { events: { // Installation event handler 'app:installation': async (event) => { const { bot_token, organization_id, team_ids } = event; // Store bot token securely // Initialize app for the organization }, // Ticket comment event handler 'ticket:comment:added': async (event) => { const { payload: { comment: { content, author }, ticket: { id: ticketId } } } = event.message; // Process new comment // Update external systems } } } ``` ### Activities Activities are pre-configured HTTP operations: ```json theme={null} // Example activity definition { "name": "create_contact", "description": "Creates a new contact in Hubspot", "http_config": { "headers": { "Content-Type": "application/json", "Authorization": "Bearer ${configuration.required_settings.hubspot_api_key}" }, "httpVerb": "POST", "endpoint_url": "https://api.hubapi.com/crm/v3/objects/contacts" }, "request_schema": { "properties": { "email": { "type": "string", "description": "Contact's email address" }, "company": { "type": "string", "description": "Company name" }, "lastname": { "type": "string", "description": "Contact's last name" }, "firstname": { "type": "string", "description": "Contact's first name" } } }, "response_schema": { "id": { "type": "string" }, "metadata": { "type": "object", "description": "Additional information about the created contact" }, "createdAt": { "type": "string" }, "updatedAt": { "type": "string" }, "properties": { "type": "object" } } } ``` # All entries Source: https://docs.thena.ai/changelog/all Complete history of updates and changes to the Thena platform. ## 📢 September 4, 2025 ## Broadcasts Create and manage broadcast campaigns to communicate with your customers simultaneously across multiple channels. Whether you're announcing new features, sharing important updates, or conducting surveys, broadcasts help you reach your entire customer base efficiently and consistently.- Automated CSAT surveys delivered via Slack or email
- Customizable survey appearance and content
- Advanced filtering rules to target specific tickets
- Sampling options to prevent survey fatigue
- Detailed analytics to track customer satisfaction trends
🔮
Status
Trial, Active, Churned, Acquired, Alpha, Prospect
📚
Classification
Mid market, SMB, Strategic, Enterprise
🔋
Health
Yellow, Green, Red
📊
Industry
Finance, Healthcare, Retail, Technology
When you select a conversation thread, you can:
- View the complete conversation history in chronological order
- See customer information including name, email, and verification status
- Monitor AI agent responses
- Track message attachments and file uploads
- Provide feedback on AI responses
The left side shows all conversations with key information at a glance:
- Customer avatar and name (or "Anonymous user" for unidentified visitors)
- Conversation title automatically generated from the discussion topic
- Timestamp showing when the conversation was last updated
- Ticket badges for conversations that have been converted to support tickets
- Verification status for customers who have been identified
When you select a thread, the right panel displays:
- Customer header with name, email, and total message count
- Message history with proper formatting for text, code, and links
- Attachment previews for files and images shared during the conversation
- Feedback indicators showing team feedback on AI responses for improvement
Execution details
Each execution log provides:
- Flow name – Which flow was triggered (e.g. L1 Deflection, Title Generation).
- Trigger source – What caused the flow to run (e.g. new ticket, workflow condition met).
- Input value – The actual content, message, or field that triggered the flow.
- Output value – What the agent generated as a result (summary, title, status update, etc.).
- Execution time – When the flow was triggered.
-
Review what your AI is doing in real time.
-
Debug or refine prompts and workflows.
-
Improve quality by analyzing outputs at scale.
-
Maintain transparency and governance around automation.
Connected views
Executions that are triggered via workflows will also appear in the Workflow Execution History—giving you visibility from both the agent and workflow lenses.
- **Capture and store:** Your feedback is stored along with the context of the AI's action. This includes the input it received and the output it generated.
- **Review and analyze:** Our team periodically reviews the feedback to identify patterns and areas for improvement.
- **Iterate and improve:** Your insights directly influence the development of our AI, helping us make it smarter and more effective over time.
Memory
Maintains account-level memory, allowing the agent to recall aggregate account history and context across multiple conversations.
Entitlements
The agent has its own authorizations across services it has access to, allowing for more granular control on the actions that the agent can take.
Knowledge retrieval
Implements standard RAG (Retrieval-Augmented Generation) to access company knowledge, with capabilities to scrape URLs and upload files for comprehensive information access.
Multi-channel deployments
Currently available as a web deployment, with upcoming support for Slack and additional communication channels (Phone, Discord etc).
Files
You can upload documents directly to your agent's knowledge hub. Supported file types include:
- PDFs
- DOCX (Word)
File upload limits:
- Max size: 100MB per file.
- Files are processed instantly and made available to the agent in real time.
- The agent will begin using this content immediately in relevant flows like L1 deflection, summarization, or internal queries.
URLs
Provide public URLs to web pages and documentation sites. When a URL is added, the agent will:
- Scan the primary page
- Automatically crawl and index all publicly linked sub-pages
- Continuously stream and refresh that content in the background
Knowledge capabilities
Once sources are added, the agent can:
- Access the full content of uploaded documents
- Read and reference all linked public pages under each URL
- Use this information to answer questions, deflect tickets, summarize threads, or inform other flows
You can view, manage, or remove knowledge sources at any time.
Benefits
Giving your agent access to the right knowledge:
- Increases the accuracy and relevance of responses
- Ensures consistency with your brand and documentation
- Powers smarter AI flows with richer context
With just a few uploads or links, you turn your agent into a true expert on your business.
Knowledge fuels intelligence. And your agent gets smarter with every file and link you add.
Automatically resolves low-complexity tickets based on existing knowledge.
Use case:
Deflect common "how-to" or informational queries for specific customer segments via email channel only. You maintain full control over which audiences this applies to.
Workflow condition:
If account = commercial and source = email → Enable Jamie's L1 deflection
Generates concise, useful titles based on the ticket conversation.
Use case:
Enable title generation only for Slack channels tagged with #product-feedback. Keeps inbound feedback organized and readable for PMs.
Workflow condition:
If source = Slack and tag = product feedback → Enable AI title generation
Jamie reads entire conversations and generates quick summaries.
Use case:
Activate summaries only when tickets are escalated to Tier 2. Helps senior agents get up to speed fast.
Workflow condition:
If group = Tier 2 → Enable ticket summarization
Jamie detects context and automatically updates ticket statuses (e.g., to "Waiting on customer").
Use case:
Enable for customer-facing tickets to automatically reflect engagement status and improve SLA tracking. Jamie can shift statuses based on intent and replies.
Workflow condition:
If type = customer support → Enable status update flow
Each agent flow can be linked to Thena workflows, giving you granular control.
You can control:
- When it activates
- For which accounts or channels
- Under what priority, sentiment, or other conditions
This means agents don't just act—they act intelligently within the bounds you define.
- Track opens, clicks
- Recipient-level delivery status
- Failed tracking for invalid addresses
- Direct links to view messages
- Monitor views, reactions, replies
- Channel delivery success
- Real-time delivery confirmation
- Direct links to view messages in Slack
- Use clear, concise titles that describe the content.
- Break content into logical sections with appropriate headings.
- Include step-by-step instructions for processes.
- Add screenshots or videos for visual clarity.
- Use consistent formatting across all articles.
- Include diagrams for complex concepts.
- Add relevant tags to improve searchability.
- Link related articles to create a knowledge network.
- Use consistent terminology throughout your help center.
Design and launch a fully hosted, public-facing help center.
You can customize:
Fonts - choose typography that matches your brand.
Colors - apply your brand colors throughout the help center.
Hero section - create an engaging welcome area.
Homepage layout - organize content for optimal navigation.
Collection and article page styles - consistent reading experience.
Footer content - add important links and information.
Other configuration options include:
Custom domain setup
SEO meta fields
Open graph image configuration
Analytics integrations (e.g. Google Analytics)
- Use @ mentions to draw attention to specific team members.
- Be specific in your comments about what needs to be changed.
- Provide context for why changes are needed.
- Establish clear roles before starting collaboration (e.g., who is the final approver).
- Set expectations for response times to comments.
- Use the version history to compare changes over time.
- If multiple people are editing the same section, communicate in real-time.
- Use comments to discuss conflicting approaches rather than repeatedly changing the same content.
- Consider using the article's internal thread for longer discussions.
Collaboration permissions are based on team member roles and can be customized for each article:
Viewers
Can read articles but cannot make edits or add comments.
Commenters
Can read articles and add comments, but cannot make direct edits.
Editors
Can read, comment on, and edit articles.
Admins
Can read, comment, edit, and manage permissions for articles.
- Use a consistent naming convention for all tags (e.g., singular nouns).
- Reuse existing tags when possible instead of creating similar variations.
- Consider creating a controlled vocabulary of approved tags.
- Choose tags that directly relate to the article content.
- Avoid overly generic tags that could apply to most articles.
- Include both technical terms and common language alternatives when appropriate.
- Aim for 3-5 tags per article for optimal searchability.
- Too few tags limit discoverability; too many dilute relevance.
- Prioritize the most important concepts rather than tagging every minor topic.
Tag management tools.
Access tag management from the knowledge base settings:
- View all tags currently in use across your knowledge base.
- Merge similar tags to reduce duplication.
- Rename tags to improve clarity or consistency.
- Delete unused or irrelevant tags.
- See which articles use each tag.
🔐 Every Thena user has access to a personal API key.
- Your API key is unique to your account and tied to your user-level permissions.
- You can view and regenerate your key by heading to Settings → Security & access.
- After regenerating, your old key will be deactivated immediately.
🧱 If you prefer not to use your personal key—or want to build integrations that aren't tied to a specific user—you can create an app in Thena:
- Go to Settings → Apps and click Create app.
- Each app comes with its own API key and can be scoped with specific permissions.
This is recommended for long-term integrations, third-party services, or production environments.
🛠 Follow these guidelines to keep your API keys secure:
- Use environment variables to store and reference API keys in your code.
- Rotate your keys periodically for security.
- Create separate apps for staging, dev, and production environments to isolate access.
- Audit access regularly through the Thena dashboard.
🔑 If you're logged in, you can reset your password anytime from your account settings:
- Go to Organization settings → Personal → Security & access.
- Click Reset password.
- Enter your current password, then choose a new one.
✅ This method ensures you're in control of your password while actively logged in.
📧 Forgot your password or can't log in? No worries.
- Go to the sign-in page.
- Click Reset password.
- Enter your email address.
- You'll receive a reset link via email.
- Click the link to set a new password and regain access.
⏳ Reset links expire in 48 hours. If yours has expired, just click Resend on the sign-in page to get a fresh one instantly.
🛡 Follow these best practices for password security:
- Use a strong password—we recommend at least 12 characters with a mix of letters, numbers, and symbols.
- Reset your password regularly for improved security.
- Reach out to your admin or support if you're having trouble accessing your email.
•
Access to your domain's DNS settings (via GoDaddy, Cloudflare, AWS Route 53, etc.)
•
Admin access to your email provider (Gmail, Outlook, etc.)
Email that works for modern support teams
Thena's email integration transforms legacy communication into a modern, structured workflow—fully embedded in your ticketing and customer support operations.
✓
Works out of the box
No complex setup required
✓
Scales with custom domains
Brand your communications
✓
Powered by smart workflows
Automate routine tasks
✓
Seamless across teams
Collaborate without friction
•
Microsoft Teams license for each user.
•
Global admin privileges (for Graph API access).
- Instant AI-powered responses using your own documentation
- Seamless handoff to human agents when needed
- Fully customizable appearance to match your brand
- Easy deployment with a simple JavaScript snippet
Logo
Add your company's logo using a public URL. Supported formats include SVG, PNG, JPG, JPEG, and WebP. This logo appears at the top of the chat interface for a fully branded experience.
Theme color
Set a start and end hex color to define your theme gradient. You can use a solid color (by leaving the end color empty) or a gradient with a custom direction (e.g., 135deg).
Position on screen
Choose where the chat widget appears. The default is bottom right, but other positions are available depending on your site layout.
Widget type
Select between Thena's default widget or link the chat experience to a custom launcher on your site.
Behavior toggles
- Use custom launcher button: Replace the default launcher with your own UI element.
- Initial dark mode: Automatically open the widget in dark mode.
- Auto-close on outside click: Automatically close the chat when users click outside the widget.
Define the tone and style of communication: Ensure the AI's personality aligns with your brand voice.
Set boundaries: Control what the AI can and cannot discuss to keep conversations on-topic.
Guide responses: Instruct the AI on how to handle specific types of queries for consistent support.
The prompt acts as instructions for your AI agent, making it feel less robotic and more like a genuine brand ambassador for your company.
Allowed domains
You must specify allowed domains to secure your deployment. These should include the full URL (http or https) for each site where the widget will be embedded.
Installation code
Once you've configured the widget, you'll get a JavaScript snippet to add to your website. This code includes:
- Your unique widget ID
- Color configuration and UI behavior (e.g., gradient direction, dark mode)
- Optionally, HMAC-based verification for secure identity handling
HMAC Authentication for User Identity
For enhanced security, you can use HMAC (Hash-based Message Authentication Code) to verify user identities. This prevents unauthorized users from impersonating others in your chat widget.
Step 1: Generate the HMAC hash on your server
You need to hash the pair of email:username with your HMAC secret. Here's a sample implementation:
```typescript theme={null} const generateHmac = (email: string, name: string): string => { const hmacSecret = <Step 2: Include the hash in your widget configuration
This hash is then sent in the SDK initialization code as shown below:
```html theme={null} ```Security considerations
The HMAC secret key is shown only once and must never be exposed in client-side code. Store it securely on your server and use it to generate valid hashes.
Chat Widget
Once the widget is deployed, your users can interact with it directly from your website.
AI-native interactions
The AI agent responds using your uploaded documentation and custom prompt. Whether it's FAQs, onboarding steps, or advanced product guidance, your AI agent becomes a 24/7 frontline support companion.
Human agent handoff
When needed, the AI can initiate a handoff by creating a support ticket. Once a ticket is created:
- The conversation is logged.
- A human agent can take over the chat seamlessly from within the same widget.
- The user experiences no disruption in their conversation.
As seen in the example with James, the AI agent gathered initial input, created a ticket, and handed it off to Jackson, a real human agent.
Image attachments
The Web chat widget supports image attachments, allowing users to share visuals for clearer communication. Supported formats include PNG, JPEG/JPG, GIF (non-animated), WebP, and BMP (partial support).
We'll be expanding support for additional file types in future updates.
Unread message notifications
The widget helps users stay updated with unread message notifications. A badge on the floating widget shows the number of conversations with new replies.
Inside the widget, a red dot highlights the specific chats that have new messages.
- When a ticket is created: responds when a new ticket is submitted.
- When a message is received: responds when a message is sent on an assigned ticket.
- Outside business hours.
- During holidays (you can select specific holidays).
- When assigned member is unavailable or on leave.
- When assigned group is unavailable or on holiday.
- Ticket status, priority, or type.
- Tags, assignee, or escalation status.
- Customer email, account, or AI-generated summaries.
Example:
Thanks for your message!
Our team is currently out for Memorial Day and will return on Tuesday. We'll get back to you shortly.
Trigger: When a ticket is created
Message: "Thanks for reaching out. We've received your request."
Trigger: Ticket created
Condition: During holidays → July 4th
Message: "We're offline today for Independence Day. We'll respond as soon as we're back."
Trigger: Message received
Condition: Outside business hours
Message: "Hey! Our team is currently offline. We'll get back to you during our working hours."
Trigger: Ticket created
Filter: Account plan field is "Basic"
Message: "Thank you for contacting us. As a Basic plan user, your request will be addressed within 48 hours. To receive faster support, consider upgrading to our Premium plan."
✨
Comprehensive CSAT solution
Create targeted rules to collect feedback at the right time from the right customers.
This section defines the metadata of your CSAT rule:
- Rule name: Give your rule a recognizable name, such as "High priority tickets."
- Description: (optional) Add any context for your team.
- Active toggle: Only active rules will send CSAT surveys. Inactive rules will be saved but not executed.
Filters define which tickets are eligible to receive a CSAT survey.
Match all conditions
All conditions in this group must be true to trigger a survey. For example:
- Priority equals High
- Status equals Resolved
- Type equals Incident
You can apply filters on ticket, account, or contact fields.
Match any conditions
If any condition in this group is true, the survey will be triggered. For example:
- Sentiment contains Positive
This is useful when you want broader but still targeted coverage.
This section defines how often CSAT surveys are sent once tickets meet the filter conditions.
Random sampling
Send CSATs to a subset of eligible tickets:
- 1 out of 10 tickets (10%)
- 1 out of 5 tickets (20%)
Use this to reduce survey fatigue or for A/B testing.
Always send
Send a CSAT for every ticket that meets the criteria—no sampling involved.
This section lets you define the survey format and appearance.
Choose feedback type
- 5-star rating: Ask customers to rate their experience from 1 to 5 stars.
- Thumbs up/down: Ask for a simple positive or negative response.
Choose delivery channel
-
Source-based delivery:
- If the ticket is from Slack, the CSAT survey is sent in the ticket thread as an ephemeral message that mentions the requester.
- If the ticket is from email, the survey is delivered via email.
-
Email override:
- You can force all CSATs to be delivered via email, regardless of where the ticket originated.
Customize survey content
You can modify the following elements:
- Survey title (e.g., "How would you rate your experience?")
- Survey message (e.g., "Please let us know how we did with your recent support request.")
- Thank you message
- Branding color: This controls the primary color used for buttons and rating icons.
-
Comment field: You can enable an optional open-text field for additional feedback.
- Customize the field label and placeholder text.
Click the "Preview" tab to see how your CSAT survey will appear to customers.
- Email preview shows the subject, ticket details, rating component, and optional comment field.
- Slack preview shows how the survey will be delivered as a message in the requester's thread.
You can switch between email and Slack views to compare formats.
Click "Settings" from the CSAT overview screen to configure global rules that apply to all CSATs.
Delivery delay
Set how many days after a ticket is closed a CSAT survey should be sent (e.g., 14 days). This gives customers breathing room before being asked for feedback.
Customer cooldown
Set a cooldown period (e.g., 10 days) to ensure a customer doesn't receive multiple CSATs within a short timeframe. This prevents survey fatigue.
Trigger statuses
Choose which ticket status triggers the CSAT survey. By default, surveys trigger on Closed tickets.
Sender email
Decide which email address will be used to send CSAT surveys. You can use the default or configure a custom one.
Once everything is configured:
- Click "Create rule" to save your setup.
- Make sure the rule toggle is set to Active if you want it to go live immediately.
- Set appropriate delivery delays to give customers time to experience the full impact of your solution.
- Use cooldown periods to prevent survey fatigue.
- Consider sending surveys shortly after resolution for technical issues, but allow more time for complex solutions.
- Use filters to target specific ticket types that would benefit most from feedback.
- Consider sampling for high-volume, low-complexity tickets.
- Always survey after critical incidents or high-priority tickets.
- Keep surveys short and focused.
- Use the right delivery channel based on where the customer is most engaged.
- Personalize the survey message to increase relevance.
- Make the comment field optional to reduce friction.
✨ Add specific emoji reactions to ticket messages to trigger actions automatically.
- Change ticket status.
Status changes are performed instantly and recorded in the ticket timeline for transparency.
- Use emoji reactions to change ticket status.
- Quickly move tickets between open and resolved states.
- Status changes are recorded in the ticket timeline.
- Configure status change emoji actions for different teams.
- Customize status workflows based on team needs.
Streamline status changes.
Teams use emoji actions to speed up these common scenarios:
- Quickly resolving completed tickets.
- Reopening tickets that require additional attention.
- Managing ticket status transitions efficiently.
Forms are customizable layouts used to collect structured data from users—whether customers, agents, or teammates. Each form consists of one or more fields, and you can define who can view, edit, or be required to fill them.
Forms are used:
- During ticket creation (web, Slack, chat, or API).
- To control what appears in the ticket view.
- To guide agents and customers through dynamic data capture.
- To power downstream automation, workflows, and analytics.
Before creating a form, you need fields.
Standard fields (built-in by Thena)
- Requester (mandatory)
- Title (mandatory)
- Status
- Assignee
- Account
These are common across all tickets.
Custom fields (user-defined)
You can define custom fields to match your specific workflow:
- Text inputs
- Dropdowns
- Date pickers
- Multi-selects
- Toggles
- Cascading fields based on logic
For detailed information on standard fields and how to create custom fields, see the Ticket fields guide.
- Name your form.
- Give a description.
- Requester and Title are mandatory.
- Add any standard or custom fields needed for your workflow.
- Use drag-and-drop to reorder.
- Visible in customer portal
- Editable by requester
- Required on creation
- Required on close
- Add logic to dynamically show or hide fields.
- Example: Show "Escalation reason" if Priority = High.
- Conditions override default field settings.
- Instantly toggle between Agent view and Requester view.
- Once saved, the form becomes selectable during ticket creation.
Forms unify the ticket creation experience—no matter where it starts.
Once a ticket is created with a form:
- The form appears on the right-hand panel of the ticket.
- Agents can view or switch forms.
- Fields reflect form-level visibility, permissions, and logic.
- Customers can update editable fields via the customer portal.
- All updates sync in real time and are fully auditable.
- Use forms to enforce consistent ticket intake across teams.
- Create templates for common ticket types.
- Establish naming conventions for fields and forms.
- Use field descriptions to guide users.
- Keep forms as short as possible while capturing necessary information.
- Group related fields together for better user experience.
- Use conditional fields to show relevant fields based on input.
- Create team-specific forms (e.g., Customer Support vs IT).
- Regularly review and prune unused fields/forms.
- Align forms with the metrics you want to report on.
- Include fields that will help with categorization and analysis.
- Consider how form data will be used in dashboards and reports.
- Product version
- Type of issue (bug, feature request, feedback)
- Customer segment
- Steps to reproduce
- Urgency level
- Preferred contact time
- Device or asset ID
- Affected system or app
- Error message or code
- Is this blocking work? (Yes/No)
- Location (onsite or remote)
- Desired resolution time
✨ Internal threads live within a ticket and are meant for internal discussion. You can:
- Loop in other teams like engineering or product.
- Share updates or decisions.
- Attach files or media.
- Link discussions to Slack channels.
These threads are only visible to your internal team—customers never see them.
⚙️ From Thena:
- Open any ticket from your Customer support → Tickets view.
- Click on the Internal threads tab.
- Start a new thread or view existing ones.
- Optionally connect the thread to a Slack channel for live triage.
If triage is enabled on your workspace, a default internal thread is auto-created and connected to the appropriate Slack channel.
🔍
View ticket
Open the ticket directly in Thena.
📊
See metadata
View ticket details and context.
⚡
Take action
Assign, resolve, or update status.
- A new ticket is created in the destination team with a new ticket number.
- The original ticket is archived and marked with migration details.
- Both tickets are automatically linked as related for a complete audit trail.
- All conversation history is copied to the new ticket.
- File attachments and internal notes are transferred.
- Internal threads from both Slack and the platform are also transferred.
- Custom field values specific to a team are not transferred.
- Ticket activity records the migration for both tickets.
- The destination team's SLA timeline starts fresh.
- The source team's SLA is paused and CSAT surveys are cancelled.
- The new team's auto-responders and workflows are applied.
- Team-specific statuses, priorities, and types are mapped.
Scenario: A customer reports a login issue that appears to be a backend bug.
- The support team creates the initial ticket SUP-245.
- After initial triage, they move it to Engineering as ENG-892.
- The engineering team gets the full context and can reproduce the issue.
- The customer continues communicating in the same Slack thread.
- Both teams maintain separate SLA and performance metrics.
Scenario: A customer requests a refund through general support.
- Support receives the request as SUP-156.
- They move it to the Billing team as BILL-089.
- The billing team sees all previous customer communication.
- The customer receives the Billing team's auto-responder with updated expectations.
- Finance processes the refund with complete context.
Scenario: A customer suggests a feature improvement during a support interaction.
- Support documents the feedback in SUP-301.
- They move it to the Product team as PROD-78.
- The product team can analyze the feature request with customer context.
- The original support ticket is resolved, and the product ticket continues internally.
- The customer stays informed about their feature request.
🎯 Ticket number changes
Customers will see a new ticket number when communicating about the issue (e.g., SUP-123 becomes SEC-456). However, they continue using the same communication channel.
⏰ SLA timeline reset
The destination team gets a fresh SLA timeline, which may extend the total resolution time from the customer's perspective.
🔐 Team permissions required
You can only move tickets to teams where you have access. Private teams require membership.
📋 Form compatibility
Custom field values transfer when compatible between team forms. Incompatible fields are preserved in the archived ticket.
Related tickets lets you link any ticket with another ticket across your entire organization, regardless of team or origin (e.g., support, billing, product, sales).
This creates a unified thread of context, so no matter where a conversation starts, it never gets siloed.
You can relate multiple tickets and remove links just as easily. It's built for scale—whether you're stitching together 2 threads or 20.
🚀
Built for multi-team operations
Each with its own triage, automation, and reporting setup.
- Use consistent ticket creation processes across all channels and teams.
- Establish clear naming conventions for ticket titles and tags.
- Create standardized forms for common ticket types to ensure data consistency.
- Implement uniform SLA policies based on ticket priority and customer tier.
- Use tags strategically for categorization and easy filtering across large ticket volumes.
- Link related tickets to maintain context across complex multi-part issues.
- Leverage account mapping to provide agents with customer context and history.
- Create custom views for different team workflows and save frequently used filter combinations.
- Use internal threads for cross-team discussions without cluttering customer-facing conversations.
- Document decisions and solutions in notes to build institutional knowledge.
- Set up proper team routing and assignment rules to ensure tickets reach the right expertise.
- Establish clear escalation paths and use ticket moves when specialized knowledge is needed.
- Configure workflows to automate repetitive tasks and ensure consistent processes.
- Set up auto-responders to manage customer expectations during off-hours or high-volume periods.
- Use AI-powered ticket creation to capture issues automatically from communication channels.
- Implement CSAT surveys to gather feedback and continuously improve service quality.
- Track SLA performance and set up alerts for potential breaches to maintain service levels.
- Monitor ticket volume patterns to optimize team capacity and resource allocation.
- Use activity logs and AI logs to identify process improvements and training opportunities.
- Regularly review and clean up unused tags, forms, and workflows to maintain system efficiency.
- Set up forms with product version, issue type, and customer tier fields for consistent intake
- Configure SLA policies based on customer classification (Enterprise, Pro, Basic) with different response times
- Enable email integration and Slack channels for automatic ticket creation from customer inquiries
- Create routing rules to assign tickets to specialized teams based on product or issue type
- Implement escalation workflows that move high-priority tickets to senior agents after SLA thresholds
- Use internal threads to collaborate with engineering teams on technical issues without exposing discussions to customers
- Set up CSAT surveys to automatically collect feedback after ticket resolution
- Create custom views for agents to track their assigned tickets, urgent issues, and pending customer responses
- Create forms with asset ID, location, department, and business impact fields for comprehensive issue tracking
- Set up routing rules to assign tickets based on location (on-site vs remote) and expertise required
- Configure SLA policies with different response times for critical systems vs general requests
- Use tags to categorize tickets by system type (network, hardware, software, security) for reporting
- Implement approval workflows for change requests that require management sign-off
- Create related ticket workflows to link incidents to underlying problems or planned maintenance
- Set up auto-responders for after-hours requests with expected response timeframes
- Use custom fields to track asset warranties, maintenance schedules, and resolution documentation
- Configure forms to capture lead information, company size, budget, and timeline for qualification
- Set up account mapping to link all sales interactions to prospect accounts for relationship visibility
- Create routing rules to assign demo requests to appropriate sales engineers based on product expertise
- Use internal threads to coordinate between sales, solutions engineering, and legal teams during deals
- Implement workflows to automatically create follow-up tasks and schedule check-ins after demos
- Set up custom views to track pipeline stages, upcoming renewals, and high-value opportunities
- Configure handoff processes to move won deals from sales to customer success with complete context
- Use tags to categorize prospects by industry, use case, and deal size for targeted outreach
- Create custom forms for feature requests with fields for use case, business impact, and affected users
- Set up routing to automatically assign product feedback tickets to product managers by feature area
- Use tags to categorize feedback by product area, priority level, and development effort required
- Implement workflows to create related tickets in engineering systems (Jira, Linear) for accepted features
- Configure internal threads to facilitate discussions between product, engineering, and design teams
- Set up custom views to track feature request volume, top requested features, and customer impact
- Use account mapping to prioritize feedback from high-value customers and strategic accounts
- Create workflows to automatically notify customers when requested features are released
• Ticket updated
• Ticket status changed
• Ticket comment added
• Ticket assigned/reassigned
• Email received
• Form submission
• External app events
• Scheduled/timer events
• Change status or priority
• Assign to agents or teams
• Add comments or notes
• Set due dates
• Email stakeholders
• Create announcements
• Update external systems
• Log activity
• Create or modify records
• Sync with external databases
• Generate reports
• Archive data
• Branch based on conditions
• Loop through data sets
• Error handling and retries
• Workflow orchestration
• Calls: Phone conversations
• Emails: Email threads
• Chat: Instant messaging
• Reviews: Performance discussions
• Presentations: Product demos
• Training: Customer education
• Include all relevant details
• Link to related records
• Maintain consistent format
• Categorize properly
• Tag all participants
• Set appropriate privacy
• Billing contact: Financial matters
• Technical contact: Implementation and support
• Executive sponsor: Strategic relationship
• Team managers
• Project leads
• Subject matter experts
• Meeting minutes
• Decision records
• Strategy documents
• Configuration changes
• Integration notes
• Troubleshooting logs
• Use consistent formatting
• Include relevant context
• Maintain objectivity
• Apply appropriate tags
• Link related notes
• Set proper visibility
• Parent-subsidiary relationships
• Multi-level account management
• Comprehensive data tracking
• Flexible classification system
• Workflow automation
• Custom field support
• API-first architecture
• Business identifiers
• Industry classification
• Account health tracking
• Territory management
• Partner relationships
• Contact management
• Team associations
• Access controls
• Industry-specific metrics
• Custom scoring models
• Compliance requirements
• Integration mappings
• Business unit specific data
• Account reviews
• Training sessions
• Issue resolution
• Resource allocation
• Process reviews
• Documentation updates
• Define ownership
• Track dependencies
• Monitor progress
• Share context
• Escalate blockers
• Document decisions
• Choose appropriate field types
• Set helpful default values
• Add descriptive hints
• Consider source-specific needs
• Archive unused fields
• Document field purposes
• Maintain consistent naming
• Monitor cross-source relationships
• Provide helpful error messages
• Use appropriate validation types
• Test edge cases
• Consider source-specific needs
• Provide clear guidance
• Offer error resolution
• Log validation issues
• Handle cross-source validation
User: [alice@acme.com](mailto:alice@acme.com)
Creates: "Acme Corp"
Domain: acme.com
Setting: Allow domain joining
User: [bob@acme.com](mailto:bob@acme.com)
Creates: "Acme Inc"
Domain: acme.com
Setting: Restrict domain joining
User: [carol@acme.com](mailto:carol@acme.com)
Options available:
Options available:
• Join "Acme Corp" (available due to domain matching and allowed joining)
• Create new org (cannot use names "Acme Inc" or "Acme Corp" with acme.com domain)
• Member: Standard access
• Viewer: Read-only access
• Custom permission sets
• Resource-level permissions
Organization administrators have comprehensive access to manage their organization's resources, settings, and members. This is the highest level of access within an organization.
Organization users have full access to operational features within their organization for daily work. This is the standard role for most team members.
Lite users have limited access focused on essential ticket management and viewing capabilities. This role is ideal for users who need basic access without full operational permissions.
Customer administrators manage customer-facing portal features and customer organization settings. This role is designed for customers who need administrative control over their portal experience.
Customer users have access to customer-facing features and their own tickets through the customer portal. This is the standard role for end customers using the platform.
Scenario: A new employee joins your organization and needs access to the platform for daily work.
Scenario: A contractor, part-time employee, or external collaborator needs limited access to specific tickets.
Scenario: An existing team member is promoted to a management role and needs administrative access.
Scenario: External customers need access to submit tickets and track their support requests.
• Team Lead: Operational oversight
• Resource Manager: Asset control
• Configuration Manager: Settings access
• Observer: Read-only access
• Guest: Limited access
• Trainee: Supervised access
• Modify access: Can edit
• View access: Read only
• No access: Restricted
• Document access
• Tool usage
• Data visibility
• Broad responsibility areas
• Cross-functional groups
• Regional divisions
• Project teams
• Product teams
• Support tiers
• Open for viewing and joining requests
• Transparent workflows
• Invitation-only membership
• Protected resources
• Team Lead: Operational management
• Member: Standard access
• Observer: Read-only access
• Resource access
• Configuration rights
• Member management
• Load-based balancing
• Priority-based routing
• Skill-based matching
• Direct agent assignment
• Escalation paths
• Fallback rules
• Capacity management
• Priority weighting
• Queue monitoring
• Priority escalation
• Team escalation
• Manager notifications
• Slack channel association
• Explicit customer reference
• Customer contact lookup
• Automatic account creation
**Secondary domains:** Additional domains (acquisitions, subsidiaries)
**Public domains:** Excluded from automatic mapping
**Success tracking:** Monitor mapping accuracy
**Conflict reporting:** Identify mapping issues
• Temporary email addresses
• Unusual domain configurations
• Legacy data migration issues
• Strategic partnership tickets
• Escalated support cases
• Compliance-sensitive situations
Provided?"} %% Step 1: Account ID with Fallback Logic B -- Yes --> C["Find Account
by ID"] C --> D{"Account
Found?"} D -- Yes --> E["✅ Account
Successfully
Linked"] D -- No --> F["⚠️ Account ID
Not Found
Continue Fallback"] E --> G{"Has Slack
Channel Info?"} G -- Yes --> H["Check Metadata
Update Needed"] G -- No --> AUDIT["Create
Activity Logs"] H -- Updated --> H1["✅ Account
Updated"] H -- No Update --> AUDIT H1 --> AUDIT %% Step 2: Slack Channel ID Lookup (including fallback cases) B -- No --> I{"Slack Channel
Provided?"} F --> I I -- No --> J["Skip Account
Resolution"] I -- Yes --> K["Search Accounts
by Slack Channel"] K --> L{"How Many
Accounts Found?"} L -- 0 --> M["❌ No Account
Found"] L -- 1 --> N{"Is This
Fallback?"} N -- Yes --> N1["✅ Account Found
via Fallback"] N -- No --> N2["✅ Account
Found"] L -- Multiple --> O["Try Email
Resolution"] %% Enhanced Email Resolution with Public Domain Check O --> P["Extract Email
Domain"] P --> Q{"Is Email
Domain Public?"} Q -- Yes --> R["🛡️ Skip Email
Resolution"] Q -- No --> S{"Customer
Contact Exists?"} R --> T["❌ No Account
Attached"] S -- Yes --> U["Check Contact's
Accounts"] U --> V{"Contact Account
Matches?"} V -- 1 Match --> W{"Is This
Fallback?"} W -- Yes --> W1["✅ Account
Resolved via
Fallback"] W -- No --> W2["✅ Account
Resolved"] V -- No Match --> X["Try Domain
Resolution"] S -- No --> X %% Domain Resolution (Primary & Secondary) X --> Y["Check Primary
Domain Matches"] Y --> Z{"Primary Domain
Matches?"} Z -- 1 Match --> AA["✅ Account
Found"] Z -- No Match --> BB["Check Secondary
Domains"] Z -- Multiple --> CC["❌ Multiple
Conflicts"] BB --> DD{"Secondary
Domain Matches?"} DD -- 1 Match --> EE["✅ Account
Found"] DD -- No Match --> FF["❌ No Domain
Matches"] DD -- Multiple --> GG["❌ Multiple
Conflicts"] %% Unresolved Conflicts Flow to No Account CC --> T FF --> T GG --> T %% Customer Contact Creation Flow J --> HH["Create Customer
Contact"] M --> HH N1 --> HH N2 --> HH W1 --> HH W2 --> HH AA --> HH EE --> HH T --> HH HH --> II["Process Customer
Contact"] II --> JJ{"Existing Contact
Found?"} %% Existing Contact Path JJ -- Yes --> KK{"Contact Has
Accounts?"} KK -- Yes --> LL["Use Existing
Contact with
Accounts"] KK -- No --> MM{"Auto-Create
Accounts
Enabled?"} MM -- No --> NN["Contact Remains
Without Account"] MM -- Yes --> OO{"Email Domain
Public?"} OO -- Yes --> PP["❌ Skip Account
Creation"] OO -- No --> QQ["Create Account
for Contact"] %% New Contact Path JJ -- No --> RR{"Auto-Create
Accounts
Enabled?"} RR -- No --> SS["Create Contact
Only"] RR -- Yes --> TT{"Email Domain
Public?"} TT -- Yes --> UU["❌ Skip Account
Creation"] TT -- No --> VV["Create Account
from Domain"] %% Account Creation with Flag Detection QQ --> WW["Process Account
Creation"] VV --> WW WW --> XX{"Account Creation
Result?"} XX -- Failed --> YY["❌ Multiple
Accounts Conflict"] XX -- Existing Found --> ZZ["✅ Existing
Account Found"] XX -- New Created --> AAA["✅ New Account
Created"] %% Final Account Status Check LL --> BBB{"Final Account
Status?"} NN --> CCC{"Final Account
Status?"} PP --> CCC SS --> CCC UU --> CCC YY --> CCC ZZ --> BBB AAA --> BBB CCC -- No Account --> DDD["❌ Ticket Created
Without Account"] BBB -- Has Account --> EEE["✅ Ticket Created
With Account"] %% Enhanced Audit Log Creation DDD --> FFF["📋 Create
No-Attachment
Logs"] EEE --> GGG{"New Account
Created?"} GGG -- Yes --> HHH["Create Account
Creation Log"] GGG -- No --> III["Skip Account
Creation Log"] HHH --> JJJ["Create Ticket
Attachment Log"] III --> JJJ JJJ --> KKK{"Account Info
Updated?"} KKK -- Yes --> LLL["Create
Update Log"] KKK -- No --> FFF LLL --> FFF FFF --> MMM["🎯 Ticket
Successfully
Created"] %% Enhanced Styling with New Categories classDef successNode fill:#e8f5e8,stroke:#2d5a2d,color:#1a4a1a,stroke-width:3px,font-weight:bold classDef errorNode fill:#ffeaea,stroke:#8b2a2a,color:#6b1f1f,stroke-width:3px,font-weight:bold classDef processNode fill:#f0f4f8,stroke:#4a5d6b,color:#2c3e50,stroke-width:2px,font-weight:bold classDef decisionNode fill:#fff8e1,stroke:#b8860b,color:#8b6914,stroke-width:2px,font-weight:bold classDef auditNode fill:#e3f2fd,stroke:#1565c0,color:#0d47a1,stroke-width:2px,font-weight:bold classDef fallbackNode fill:#fff0e6,stroke:#cc7a00,color:#cc7a00,stroke-width:2px,font-weight:bold classDef securityNode fill:#e6f3ff,stroke:#0066cc,color:#0066cc,stroke-width:2px,font-weight:bold classDef startEndNode fill:#f3e5f5,stroke:#7b1fa2,color:#4a148c,stroke-width:3px,font-weight:bold A:::startEndNode MMM:::startEndNode E:::successNode N1:::successNode N2:::successNode W1:::successNode W2:::successNode AA:::successNode EE:::successNode LL:::successNode ZZ:::successNode AAA:::successNode EEE:::successNode M:::errorNode T:::errorNode PP:::errorNode YY:::errorNode DDD:::errorNode CC:::errorNode FF:::errorNode GG:::errorNode HH:::processNode II:::processNode WW:::processNode FFF:::processNode III:::processNode JJJ:::processNode B:::decisionNode D:::decisionNode G:::decisionNode I:::decisionNode L:::decisionNode N:::decisionNode Q:::decisionNode S:::decisionNode V:::decisionNode W:::decisionNode Z:::decisionNode DD:::decisionNode JJ:::decisionNode KK:::decisionNode MM:::decisionNode OO:::decisionNode RR:::decisionNode TT:::decisionNode XX:::decisionNode BBB:::decisionNode CCC:::decisionNode GGG:::decisionNode KKK:::decisionNode AUDIT:::auditNode H1:::auditNode HHH:::auditNode LLL:::auditNode F:::fallbackNode R:::securityNode UU:::securityNode ``` This comprehensive flow shows how Thena systematically attempts to link every ticket to an appropriate account through multiple resolution strategies. ## Related resources
• Perfect for personal work
• No team visibility
• Convert to public when ready
• Enables collaboration
• Team can provide input
• Ready for group review
• Include key details
• Set appropriate visibility
• Use templates when available
• Use clear comments
• Track major changes
• Set review expectations
• Title and description
• Status and priority
• Creation timestamp
• Team assignment
• Agent ownership
• Related tickets
• API endpoints
• Slack
• MS Teams
• Form submissions
• Workflow triggers
• Next response time
• Resolution time
• Update time
• Customer attributes
• Time-based rules
• Custom conditions
• Pending customer response
• Third-party dependencies
• Integration sync delays
• Scheduled maintenance windows
* **Manual pauses**:
• Emergency maintenance
• Major incidents
• Planned downtimes
• Customer-requested holds
* **Business rules**:
• Only business hours counted during active periods
• Pause periods completely excluded
• Auto-resume on specific triggers
• Pause reason tracking for reporting
• First response: 30 minutes
• Resolution: 4 hours
• Update frequency: Every 30 minutes
* **Gold tier**:
• First response: 1 hour
• Resolution: 8 hours
• Update frequency: Every 2 hours
* **Silver tier**:
• First response: 4 hours
• Resolution: 24 hours
• Update frequency: Daily
* **Default**:
• First response: 8 hours
• Resolution: 48 hours
• Update frequency: Every 48 hours
• Set up multiple time zones
• Configure holiday calendar
• Specify weekend rules
• Handle timezone differences
• Skip holidays automatically
• Breach warnings
• Pause status
• Team notifications
• "Open" status created by default
• Used for new ticket creation
• Can be changed if needed
• "Closed" status created by default
• Represents final state
• Can be changed if needed
• Inherits parent properties
• Supports custom settings
• Maintains parent requirements
• Config flag available
• Moves parent tickets
• One-time operation
• Moves tickets to parent's default sub-status
• Validates ticket migration
• Allows deletion after migration
• Maintains data integrity
• Moves tickets back to parent status
• Ensures data preservation
• Allows deletion after migration
• Updates parent status
• Number → Number
• Date → Date
• Single Select → Single Select (if options match)
• Multi Select → Multi Select (if options match)
• Boolean → Boolean
• Single Select → Multi Select
• Date → Text (format issues)
• Custom field types with different schemas
• Fields with different validation rules
• Shared customer channels
• External channels
• Guest channels
• Archived conversations
• Deleted channels
• Forwarded conversations
• CC/BCC scenarios (multiple team members are copied)
• Cross domain tickets
• Shared channels
• Private channels
• Guest user conversations
• Cross-tenant scenarios
• Standard fields (assignee, status, priority)
• Built-in workflows
• Automatic SLA tracking
• Smart assignment rules
• Sub-team-based routing
• Notification system
• No standard fields
• Manual workflow creation
• No built-in SLA tracking
• Custom assignment logic needed
• Manual routing setup
• Custom notification setup
• Title and description
• Status and priority
• Assignment details
• Timestamps
• Dynamic forms
• Metadata
• Tags
• Probability percentage
• Expected close date
• Account and contacts
• Product/service details
• Competitor analysis
• Approval flows
• Quote generation
• Win/loss tracking
• Revenue forecasting
• Team notifications
• Flow control: Branch, delay
• User activities: Create, update, permissions
• Integration activities: API calls, webhooks
• **name**: Human-readable name
• **uniqueIdentifier**: Machine-readable identifier (e.g., `tickets:create-ticket-platform`)
• **version**: Activity version number
• **source**: Origin application
• **throttler**: Rate limiting configuration
• **metadata**: Additional configuration data
• User events: Created, updated, permissions changed
• Team events: Created, members changed
• Account events: Created, updated, status changed
• Email events: Received, sent, bounced
• Custom app events: Any app-specific events
• Scheduled events: Time-based triggers
• **eventName**: Human-readable name
• **eventType**: Machine-readable type (e.g., `ticket:updated`)
• **source**: Origin of the event
• **description**: Human-readable description
• **messageAttributes**: Context and metadata about the event
• **required fields**: Mandatory data points
• **properties**: Data type definitions and validations
• Complex conditional logic
• Multi-step processes
• Error handling and compensation
• Custom activity support
• API-first architecture
• Trigger conditions
• Event filtering
• Real-time processing
• Custom activities
• Activity chaining
• Error handling
• Compensation logic
• Ticket archived (`ticket:archived`): Triggered when a ticket is moved to archived status
• Ticket escalated (`ticket:escalated`): Triggered when a ticket is escalated | | Integration Events | Events from integrated apps | • Slack message (`slack:message`): Triggered when a message is sent in a channel
• Slack channel created (`slack:channel:created`): Triggered when a new channel is created | | Timer Events | Schedule-based events | • Daily report generation (`schedule:daily`)
• Weekly cleanup (`schedule:weekly`)
• Custom intervals (`cron:custom`) | ### Activities | Type | Description | Examples | | ---------------------- | -------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | System Activities | Built-in platform activities | • Create account (`accounts:create-account-platform`): Creates new account with name and domain
• Sleep (`workflows:sleep-platform`): Pauses execution for specified duration
• Update ticket (`tickets:update-ticket-platform`): Updates ticket information | | Integration Activities | Activities for external services | • Slack postMessage (`slack.postMessage-YKGGEBQJ10VM380KWBSKVYP875AJQ-EUUV8TTGY1`): Sends messages to Slack channels | | Data Activities | Data manipulation activities | • Get comment threads (`communications:get-comment-threads-platform`): Retrieves threaded comments for specific IDs | ## Associated components