> For the complete documentation index, see [llms.txt](https://docs.usepylon.com/pylon-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.usepylon.com/pylon-docs/platform/triggers/conditions.md).
# Conditions
How trigger If, Else if, and time delay conditions are evaluated, and what each condition field means.
Conditions decide whether a trigger acts on the object that kicked it off. Add them in the **If** card of a flow:
* **Condition by field** — filter on a field of the issue, account, contact, or other object.
* **Condition by AI prompt** — describe the condition in plain language and let AI decide. See [AI conditions](/pylon-docs/platform/triggers/conditions.md#ai-conditions).
All conditions in a card must match (AND). To match any of several conditions (OR), click **+ Add filter group**.
Condition for support issues from customers with spend below 5k
## How flows are evaluated
A trigger can have several flows. The first flow's conditions card is labeled **If**, and each flow after it is labeled **Else if**.
* Pylon checks flows from top to bottom and runs **only the first flow whose conditions match**. Later flows are skipped, even if they would also match.
* A flow with no **If** conditions always matches, so use one as the last flow to act as an "else". Click **Add flow** to add another flow; it's disabled while the last flow has no **If** conditions, since nothing after a catch-all flow could ever run.
* Disabled flows are skipped.
* You can also add an **If** step partway through a flow (**Add Step > If**). If it doesn't match, the flow stops there. Actions before it have already run, and Pylon doesn't fall through to other flows.
* To stop a trigger without changing anything for some objects, put a flow above the others with the **Take no action** action.
Conditions are checked against the object as it is when the trigger runs. On **Issue has a new message** kickoffs, the last-message fields (**Last Message From**, **Last Message Body**, **Last Message Source**) use the message that fired the trigger. On **New issue created**, they use the issue's first message.
## Issue conditions
On issue triggers, the filter menu groups fields by what they describe:
* **Issue filters** — the issue itself.
* **Account filters** — the issue's account.
* **Contact filters** — the issue's requester.
* **User filters** — the issue's assignee.
Custom fields for issues, accounts, and contacts (the requester) are also available. Some fields only appear once you've set up the feature they depend on, such as teams, tags, ticket forms, or the customer portal.
### Messages and direction
| Field | What it checks |
| ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Issue Direction** | **Inbound** if a customer started the issue, **Outbound** if your team did. See below. |
| **First message from** | Who wrote the issue's first message: **Customer**, **Your Team**, or a specific team (the author belongs to it). Internal notes don't count. For Slack issues, this is the message that started the thread. |
| **Last Message From** | Who wrote the latest message, with the same options. |
| **Last Message Body** | The text of the latest message. Not case sensitive. |
| **Last Message Source** | The channel the latest message came through, such as Slack or Email. |
| **Issue Body** | The content of the issue's original message. |
| **Email Subject** | The subject of an email issue. |
**Issue Direction** is set when the issue is created:
| Channel | Inbound when |
| --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Slack | A customer wrote the message that started the thread. If a teammate started it, the issue is outbound, even if a customer replies or adds the ticket emoji. Pylon prompts such as the floating bar and question prompt count as inbound; [broadcasts](/pylon-docs/broadcasts/overview.md) count as outbound. |
| Microsoft Teams, Discord, and other chat apps | A customer created the issue: they wrote the message, or they added the ticket emoji. If a teammate tickets a customer's message, the issue is outbound. |
| Email | Inbound, except a thread a teammate started from their synced [personal inbox](/pylon-docs/account-intelligence/accounts/personal-email.md), which is outbound. |
| Chat widget, forms, imports | Always inbound. |
| Phone | Inbound calls are inbound; outbound calls are outbound. |
| API | Inbound when the issue is created on behalf of a contact; outbound otherwise. |
| Created in Pylon | Always outbound. |
{% hint style="info" %}
There's no condition for a specific person who wrote a message or started a Slack thread. Use **First message from** or **Issue Direction** to tell customers from your team, or a **Contact filters** field such as **Contact Email** to match the requester.
{% endhint %}
### Assignee
| Field | What it checks |
| --------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Assignee** | Who the issue is assigned to, or **No Assignee**. |
| **Member of Team** | Whether the issue's **assignee** belongs to a team. Membership in a subteam counts as membership in its parent team. This differs from **Team**, which checks the team the issue is assigned to. An unassigned issue never matches **is any of**, and always matches **is not any of**. |
| **Assignee Status** | The assignee's [user status](/pylon-docs/support-workflows/assignment-rules/user-status.md). A user in a custom status matches that custom status, not the built-in status it's based on, so select custom statuses explicitly. |
| **Assignee Is Deactivated** | Whether the assignee's account has been deactivated. |
| **Follower** | Teammates following the issue. |
### Channel and source
| Field | What it checks |
| ---------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Issue Source** | The channel the issue was created in, such as Slack, Email, Chat Widget, or Form. |
| **Creation Method** | How the issue was created: Ticket Emoji, Bot Mention, Floating Bar, All Messages Are Issues, Question Prompt, Feed Message, Community, API, Dashboard, or Import. |
| **Channel** | The Slack or Discord channel the issue was created in. |
| **Created in Primary Channel** | Whether the issue was created in its account's primary external channel. |
| **Workspace Email** | Which of your connected email addresses received the issue. |
| **To Email** | The To recipients of the issue's original email. |
| **From Email** / **CC Email** | The sender and CC recipients of the issue's original email. |
| **Latest Email CCs** | The CC recipients of the most recent email on the issue. |
| **Chat Widget App**, **Phone Number**, **WhatsApp Number** | Which chat widget, support phone number, or WhatsApp number the issue came through. Shown when you have more than one chat widget, or any phone or WhatsApp numbers. |
| **Form** | The [ticket form](/pylon-docs/support-workflows/ticket-forms.md) the issue was created from or that was submitted on it. |
### Time
| Field | What it checks |
| ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Support Hours** | Whether the trigger is running **In Support Hours**, **Outside Support Hours**, or **On Holiday**, based on the [support hours](/pylon-docs/support-workflows/support-hours.md) that apply to the issue. |
| **Current Time** | Whether the trigger is running inside or outside a support hours schedule you pick. Not available on **Recurring schedule** triggers. |
| **Created At** | When the issue was created. |
### Other issue fields
These work the way their names suggest:
* **Issue Status**, **Issue Type** (Ticket or Conversation), **Team**, **Issue Tags**, **Issue Topic**, **Snoozed**
* **Created from Split**, **Is Issue Group**, **Customer Portal Visibility**, **Language**, **Message Redaction Used**
* **Parent Issue Group** — whether the issue is a child in an [issue group](/pylon-docs/support-workflows/issues/issue-groups.md). Issue groups themselves have no parent group.
* **Support Agent Has Responded** — one of your [support agents](/pylon-docs/agents/support-agent.md) has replied on the issue. Not available on **Recurring schedule** triggers.
* **Product Issue Source**, **Product Ticket Completion**, and linked **Jira Issue**, **Linear Issue**, **GitHub Issue**, or **Asana Task**
* **CSAT Score** and **CSAT Feedback** — only on the **CSAT survey completed** kickoff.
* Account fields such as **Account**, **Account Owner**, **Account Tags**, **Pylon Account Type**, **Parent Account**, **Issue Count (90d)**, **Last Customer Activity**, and **Last Vendor Activity**, plus channel fields such as **Primary External Channel** and **External Channel Type**.
## Account and contact conditions
* **Account triggers** can only filter on account fields: the account fields listed above, account custom fields, and **Current Time**.
* **Contact triggers** can filter on the contact (**Contact Email**, **Contact Name**, **Account**, and contact custom fields) and on the contact's account. **NPS Score** is available on the **NPS survey completed** kickoff.
## Time delays
Add a time delay with **Add Step > Time delay**. It reads **Wait** *\[amount] \[unit]* **during** *all hours* or *support hours*.
* **All hours** counts wall-clock time, in seconds up to weeks. **Support hours** counts only time inside the support hours that apply to the object, in seconds, minutes, or hours.
* Add time delay conditions to continue only **as long as** they still hold when the wait ends:
* **Issue Status Never Changes** — the issue's status hasn't changed since the wait started.
* **No Message From** — no message from **Your Team**, **Your Customer**, or **Internal Notes** (pick one or more) since the wait started.
* **Current Time** — the wait ends inside or outside a support hours schedule.
* When the wait ends, Pylon checks the time delay's conditions against the object as it is then. If they don't hold, the run stops and is logged as skipped.
* If the same trigger fires again for an object that's already waiting at that step, Pylon keeps the existing wait instead of starting a second one.
You can see and clear what's waiting in the [time delay queue](/pylon-docs/platform/triggers/logs-and-history.md#time-delay-queue).
A trigger to autoclose issues after 3 days of customer inactivity
## AI conditions
Click **Condition by AI prompt** on an **If** card, or **Filter by issue content** in the filter bar, and describe the condition (for example, "the customer is asking for a refund"). Type `{` to insert template variables such as the issue title or a custom field.
* AI conditions are available on issue triggers, including **Recurring schedule** triggers that run on issues.
* The AI reads the issue's conversation and the message that fired the trigger. If your prompt refers to the "last", "latest", or "new" message, only that message is used. Account details and other fields are only included if you insert them as variables.
* An AI condition is combined with the card's other conditions like any other filter.
* If the AI can't evaluate the condition, for example because of an error, the condition doesn't match.
Without AI Assistant features, your workspace can use two AI conditions in total across all triggers, including disabled ones. AI Assistant features include unlimited AI conditions and are available on select plans.
## Assigning to unavailable users
The **Set issue assignee** action can assign a specific user or a dynamic one: **Account owner**, a user field on the issue, account, or requester, or (on some kickoffs) the **Actor**, **Message author**, or **Reactor**. Pylon never falls back to another user:
* **Empty field or no account owner** — the assignee doesn't change.
* **Deactivated user** — the assignment is skipped and noted in the issue's activity.
* **User's status isn't allowed** — the assignment is skipped and noted in the issue's activity.
Under **Settings**, the action's **Assign only if the user's status is** picker sets which [user statuses](/pylon-docs/support-workflows/assignment-rules/user-status.md) can receive the assignment. **Set task assignee** has the same picker; when it blocks an assignment, the task's assignee doesn't change.
* A new action starts with every status in the **Available** section selected. If you keep exactly that selection, available statuses your workspace adds later are allowed too.
* Clear every status to show **Any status**. Pylon then assigns the user whatever their status is.
* Custom statuses are listed individually. A user in a custom status is assigned only if that custom status is selected. Selecting the built-in status it's based on isn't enough.
To have Pylon pick an available teammate instead, use **Set issue team** and let the team's [assignment rules](/pylon-docs/support-workflows/assignment-rules.md) choose the assignee.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.usepylon.com/pylon-docs/platform/triggers/conditions.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
