Automation Configuration

Learn how to configure the "When," "If," and "Wait" components of your automations.

Choose Your Trigger

Pick what event starts your automation:

Request Triggers

• Request Creation – New request submitted (Available in All Product Editions)

The following Request Triggers are available in Integrations & External HelpDesk Product Edition:

• Request Update – Status, priority, or field changes

• Request Message Added – New reply

• Request CSAT Submitted – Feedback received

• Request Reaction Added – Request reacted with an Emoji (you pick which one)

Ticket Triggers

Available in all Product Editions

• Ticket Creation - New ClearFeed ticket created

• Ticket Update - Field changes

• Ticket Message Added - New message

• Ticket CSAT Submitted - Feedback received on ticket

• Ticket Reaction Added - Ticket reacted with an Emoji (you pick which one)

• Approval Workflow Completed - Whenever an approval workflow is completed, whether the final outcome is approved or rejected.

• Before Approval Workflow Triggered – When selected, the automation runs synchronously before the approval workflow is initiated. Because the system waits for this automation to complete, delay steps are not supported, and the approval workflow executes only after the automation finishes.

  

  Triggers in Automations for Internal Helpdesk

Add Conditions

Conditions help narrow when your automation should run.

Conditions are optional but allow precise targeting — all conditions must be true for the automation to execute.

Standard Fields

Conditions are available on: Status, Priority, Assignee, Channel, Assigned Team, First Message Author, Customer, Source

Operators available:

• is set to / is not set to

• is one of / is not one of

Approval Workflow Fields

• Approval Workflow: The name of the approval workflow. Use this field in automations to trigger actions for a specific approval workflow.

• Approval Workflow Status: The final status of the approval workflow. Use this field to define conditions based on workflow state (approved or rejected).

Business Hours

Time-based conditions that respect your workspace timezone:

• Trigger time is inside business hours

• Trigger time is outside business hours

Custom Fields

Different field types support different operators:

Field Type	Supported Operators
Text	is set to, is not set to
Number	is set to, is not set to, is greater than, is less than
Date	is set to, is not set to, is after, is before
Single Select	is set to, is not set to, is one of, is not one of
Multi Select	contains any of, contains all of, contains none of
User Select	is set to, is not set to, is one of, is not one of

Set Delay

Delays allow actions to run after a set time:

• Default: No delay

• Maximum: 29 days, 59 minutes, 59 seconds

• Format: Days / Hours / Minutes

Cancel the Delay on Field Changes

By default, once a delay starts it counts down no matter what happens to the request or ticket. Cancellation lets you watch specific fields during the delay and automatically cancel the automation if one of them changes — so you don't run an action that no longer makes sense.

You can watch one or more fields, including standard fields (like Status or Priority) and Custom Fields.

Configure cancellation on field changes in the delay step

How cancellation behaves depends on whether the watched field is also used in the automation's Conditions:

• Field is part of your Conditions – The automation cancels only if the change makes the condition false (the request no longer matches). If the new value still satisfies the condition, the delay continues. In other words, the automation stays alive as long as the request still matches, and cancels the moment it stops matching.

• Field is NOT part of your Conditions – Any change to the field cancels the automation, regardless of the new value.

Example

You're building an automation that sends a follow-up to the Assignee when a request stays Open for 3 days, with a 3-day delay.

• Watching Status (part of your Conditions) – If Status changes to "Resolved" during the 3 days, the condition (Status = Open) is no longer true, so the automation cancels — there's no point following up on a resolved request. If Status stays "Open", the follow-up sends after 3 days as planned.

• Watching Priority (not part of your Conditions) – Any Priority change — say Medium → High — cancels the automation, even if Status is still "Open", because you told ClearFeed that any change to Priority should cancel it.

Reset Delay on New Activity

Automations with a delay step can now reset the timer when there's new activity on the request or ticket — so follow-ups only fire after the conversation has actually gone quiet.

Why this matters: Without reset settings, a delay timer starts when the automation triggers and counts down regardless of new activity. This means your follow-up alert might fire even though a follow-up was provided recently. With reset enabled, the delay restarts whenever there's new activity, ensuring actions (like alerts) only happen after genuine silence.

What Can Reset the Delay

You can choose which types of messages reset the delay timer:

• Message from a responder – Restarts the delay when a member of your support team replies

• Message from a non-responder – Restarts the delay when the requester or customer replies

Configure reset settings in the delay step

How It Works

1. Automation triggers – The automation starts when its trigger event occurs and the conditions (if any) are met

2. Delay begins – The configured delay timer starts counting down

3. New activity arrives – If a message matching your reset criteria is posted, the delay timer resets to zero and starts counting down again

4. Action executes – The automation's action only runs after the full delay period completes without any resetting activity

Note Reset Delay does not re-evaluate the trigger condition. It simply extends the delay time on specific events.

Overlap Protection

You can't configure reset events that would conflict with your trigger — this prevents infinite loops where every message would both trigger new automations AND reset existing ones.

Example: If your trigger is "Message Added," you cannot add "Message from responder" or "Message from non-responder" as reset events. The system will block this configuration to prevent automations from piling up indefinitely.

Recurring Automations

A recurring automation runs again and again for the same request or ticket, rechecking your condition on a timed cycle and taking action each time the condition is still met.

To make an automation recurring, enable the Re-enqueue automation on completion checkbox and configure both a Condition and a Delay:

• The Re-enqueue automation on completion checkbox is what makes the automation repeat. Without it, the automation runs only once, even when a condition and a delay are configured.

• The Condition tells ClearFeed when the automation should keep running. Re-enqueued automations check the Condition again.

• The Delay controls how long ClearFeed waits before each action.

Note: A condition and a delay on their own do not make an automation recurring. An automation only repeats when Re-enqueue automation on completion is enabled, so your existing one-time delayed automations are unaffected.

This is useful when you want ClearFeed to wait, recheck whether a request still needs attention, take action if it does, and then schedule itself to check again later.

When to use it: Set up a recurring automation when you want a repeated, timed check on the same request or ticket — for example, a reminder that keeps nudging a thread until someone responds.

Practical Example: For a complete end-to-end guide on creating periodic alerts for critical incidents, see Providing Timely Updates During Incidents. This guide walks through setting up recurring automations with reset delays to post periodic reminder comments on incident tickets.

How It Works

1. The automation starts when its trigger event happens.

2. ClearFeed checks the automation condition first.

3. If the condition matches, ClearFeed waits for the configured delay.

4. After the delay, ClearFeed performs the configured action.

5. Once that run completes, because Re-enqueue automation on completion is enabled, ClearFeed re-enqueues the automation for the same request or ticket.

6. The re-enqueued automation starts again from Step-2, checking the condition and repeating itself.

The automation is re-enqueued after a successful run. It is also re-enqueued if a run fails due to an action or system issue, so the automation can try again on the next cycle.

Example: Recurring Open-Request Reminder

A team can set up a recurring alert for requests that are still Open and have not received a response:

• When (Trigger): Request Updated

• If (Condition): Status is "Open"

• Wait (Delay): 4 hours

• Then (Action): Post a reminder message in the thread

With Re-enqueue automation on completion enabled, ClearFeed waits for the configured time, posts a reminder, and then re-enqueues the same check. This keeps the thread active with repeated alerts until the request is answered, closed, or no longer matches the condition.

How the Cycle Ends

The automation is not re-enqueued when the condition is no longer met — this is the normal way the recurring cycle ends.

The cycle can also stop if:

• The automation is disabled.

• The request or ticket no longer exists.

• An Invariant field change cancels the automation (as described in Invariance Settings).