How to set up and troubleshoot triggers for automated actions

Last updated: July 22, 2026

Triggers allow you to automate various actions such as sending reminders, alerts, and emails based on specific conditions. This guide covers setup, organization, and troubleshooting of triggers to help you create effective automated workflows.

Trigger Organization and Execution

Triggers execute in a specific order that's important to understand:

  • Trigger groups execute from top to bottom

  • Triggers within each group execute sequentially

  • If Group A contains triggers 1-3 and Group B follows, the first trigger in Group B would be the 4th trigger to execute overall

Best Practice: Organize triggers by function (routing triggers together, SLA triggers together) or by team as your organization scales (tier 1 support triggers, security team triggers, etc.).

Triggers will execute for each inbound email message individually, even if multiple messages arrive in rapid succession from the same sender. There is no rate limiting or freezing behavior.

Account Triggers vs Issue Triggers

Account triggers do not have a built-in "send email to account" action. There are two supported approaches to send emails from account-triggered flows:

1. Webhook action to email service (most flexible for Account-level workflows):

  • Use a "Send webhook" action that posts account details to your email provider (or Zapier) to send the email

  • Include account field variables in the webhook payload (e.g., primary_contact_email, account name)

2. Issue‑triggered flow with "send issue message" action:

  • Use an Issue‑triggered flow with a "send issue message" action

  • When the issue originated from email, this action will send an email reply to the customer

  • This fits when the notification should live in a customer‑facing issue thread

Best practices for account‑based email workflows:

  • Keep the trigger narrow with specific filters (e.g., only when field changes to a specific value)

  • Add guards to avoid repeat sends (e.g., only when previous value was different)

  • Drive recipient email from a single Account field rather than hardcoding addresses

  • Use templates with variables for account name, reason, next steps, and support contact

  • Add parallel internal alerts so team members can follow up

Time Delay Limitation: Account‑level triggers do not support the same time‑delay options available for issue‑triggered flows. As a workaround, use a two‑step workflow: (1) set a tag on new accounts, and (2) create a separate trigger that sends a reminder or follow‑up action after a specified number of days based on that tag.

Managing Inactive Triggers

To archive triggers you're no longer using while preserving their logic for reference:

  1. Create a new trigger group with a name like 'deactivated' or 'archived'

  2. Turn off the old triggers

  3. Move them into this new group

Creating Repeating Triggers

For triggers that need to repeat weekly (e.g., to ping engineers until an issue is resolved):

  1. Set the trigger to fire when issue status changes to 'On Hold'

  2. Add a wait period (e.g., 7 days)

  3. Check if status is still 'On Hold'

  4. Send notification

  5. Set status back to 'On You' or 'New' to restart the cycle

Best Practice for Recurring Reminders: Place the TIME DELAY step after sending the reminder, followed by the IF condition check. The correct flow is: send reminder → wait (time delay) → check condition (IF) → send next reminder if condition still met.

Account-Based Date Reminders

To create reminders based on account date fields (e.g., 90-day reminders):

  1. Create or identify the Account Date custom field you want to use

  2. Create a trigger on Accounts that fires when that Date field is set or updated

  3. Add a Time Delay action for the desired duration (e.g., 90 days)

  4. Add a post-delay condition to re-check the account state before the reminder executes

  5. For internal-only reminders, use internal thread or internal notification actions

Setting Up Auto-Responders

To create an auto-responder (such as for chat widgets):

  1. Navigate to the Triggers page under Settings

  2. Create a new trigger (templates are available)

  3. Define conditions for when the autoresponder should activate

  4. Set the action to 'send issue message' with your custom message

Using Filter Groups for Complex Logic

For complex conditional logic requiring multiple conditions of the same field type, use Filter Groups. When adding conditions to a trigger, click the "Filter Group" option instead of individual filters. This allows you to:

  • Set up AND conditions for the same field

  • Create multiple conditions for the same field type

  • Configure complex AND/OR logic between different condition groups

When setting up triggers that need to match one condition OR another, create separate filter groups for each condition.

Understanding Email Field Distinctions

When setting up email-based triggers, understand these field differences:

  • Contact Email: The customer's email address (the sender)

  • Workspace Email: Your company's email address that received the message

  • From Email: The original sender of the first message in the issue thread

To set up automation for customers who reach out via email, use the trigger event "Issue created" with the filter "Source = Email".

Custom Field Considerations

When working with custom field values in triggers:

  • Renaming a custom field option may not update the underlying slug, which can cause issues in webhook payloads

  • Deleting and recreating custom field options with the same name may cause triggers to silently fail

  • Pylon automatically converts hyphens to underscores in custom field value slugs

  • Custom field value slugs only support letters, numbers, and underscores. When you create custom field values with hyphens (e.g., "AI-OPTIMIZER"), Pylon automatically converts them to underscores in the slug (e.g., "ai_optimizer"), which is what appears in webhook payloads. This can cause mismatches with external systems expecting hyphenated values. You can view and edit the slugs by clicking the three dots on the right side of the custom field row in Settings → Issue Custom Fields.

  • When using custom fields as filters in trigger conditions, if the field is not properly defined on an issue, the trigger may recognize it as 'other' or 'none', causing unexpected behavior in else/if conditions. To prevent this, make critical custom fields required in your field settings to ensure the field is always populated and the trigger can properly evaluate the conditions.

Best Practice: Ensure custom field options are explicitly selected in trigger IF conditions and check that all relevant values are included in the filter list.

Common Troubleshooting Issues

Duplicate Actions

If you're experiencing duplicate actions (like multiple Slack notifications), check for overlapping triggers that perform the same action. Turn off one of the duplicate triggers to resolve the issue.

If you're experiencing duplicate actions (like multiple Slack notifications), check for overlapping triggers that perform the same action. For example, if you have one trigger for "Issue created" with a specific tag and another for "Tag changed" to that same tag, both triggers will fire when a new issue is created with that tag, causing duplicate actions. To resolve this, disable one of the redundant triggers. You can check the issue's activity log to see which triggers are firing.

Triggers Not Firing

If a trigger isn't sending messages as expected, verify:

  • Confirm the trigger is Active (toggle at the top right) and placed above any triggers that might stop it from running. Triggers run top‑to‑bottom and use AND logic on conditions

  • Kickoff: set to "New issue created"

  • Conditions: verify they match exactly how the issue is created (e.g., issue source/form identifier or a specific custom field the form sets). If any single condition isn't true or a field is unset, the trigger won't fire

  • Action: use "Send issue message" (this replies to the requester on the issue)

  • If your message references form/custom field values, add a short time delay before the send so fields finish populating; otherwise variables can be blank

Corrupted Duplicated Triggers

If you create a trigger by duplicating an existing one and it fails to execute properly, delete it and create the same trigger from scratch as a completely new trigger.

'No Message Activity' Filter Issues

Be careful when using the 'No Message Activity' filter in triggers with time delays. If any message is sent during the delay period, it will invalidate the condition and prevent the trigger from executing.

Domain Blocking

When creating triggers to exclude certain domains from creating tickets, use the 'Contains' option rather than the 'Is' option in the trigger condition.

Special Use Cases

CSAT Response Triggers

While there's no explicit trigger for CSAT responses, you can set up a workaround using notes:

  1. Set the trigger event to "when an issue has a new message" and "message is a note"

  2. Add a filter for "Last Message Body Contains" with the score text (e.g., "Score: 1")

Auto-Close Behavior

When you set up a trigger to auto-close issues, any subsequent reply from the customer will automatically move the issue back to 'On you' status, ensuring customer responses are still captured.