Scheduled Actions

REDA AI agents can propose actions to be performed in the future — such as sending an email, creating a Salesforce record, or notifying a team. When the user agrees, the agent creates a Scheduled Action record that automatically executes at the specified time or event. This article explains how scheduled actions work, how to view and manage them, and how to monitor their execution.

What Are Scheduled Actions?

A Scheduled Action is a task that the AI proposes during a conversation, and that executes automatically at a later time or based on a trigger. Instead of immediately creating a record or sending a message, the agent can schedule it for later, giving users flexibility and control.

Common Scheduled Action Examples

• Time-based: "Create a reminder task for tomorrow at 9 AM"
• Time-based: "Send a follow-up email to the customer in 3 days"
• Time-based: "Schedule a meeting request for next Monday at 2 PM"
• Event-based: "Send an email to the sales team when a reply comes in from the customer"
• Event-based: "Create a follow-up task if the opportunity doesn't move to Closed Won within 14 days"

How Scheduled Actions Are Created

During a conversation, when a user asks the AI to do something later, the agent uses the schedule_action tool to create a Scheduled Action record:

1. User asks the agent to schedule something — Example: "Remind me to follow up with John in 2 hours."
2. Agent evaluates the request — The AI determines if the request is valid and creates a Scheduled Action record using the schedule_action tool.
3. Action is stored — A Scheduled Action record is created with details (action type, execution time, data to send, etc.).
4. Agent confirms to user — The AI responds with confirmation: "I've scheduled a reminder for 2 hours from now."
5. Batch job executes later — At the scheduled time, REDA AI's batch job processes the action (checking the trigger time, or waiting for the triggering event).

Trigger Types

Scheduled Actions support two trigger mechanisms:

Time-Based Triggers

Execute at a specific date and time (UTC). The agent specifies a target execution time, and a REDA AI job that runs every 15 minutes picks up any action whose time has arrived:

• Future range: up to 30 days in advance. The agent can give an absolute time (2026-03-15T14:00:00) or relative shorthand — +2h, +1d, +1w
• Execution window: Executed on the next run of the 15-minute job after the scheduled time — so an action set for 2:00 PM UTC runs by about 2:15 PM UTC, not overnight
• Example: A trigger time of "2026-03-15 14:00:00 UTC" means the action executes on March 15 at 2 PM

Email Reply Triggers

Execute when a reply is received to a tracked email. Instead of a specific time, the trigger is an email reply event:

• Monitor tracked emails: REDA AI monitors specified email addresses for replies
• Trigger on reply: When a reply is received, the action executes immediately (not batched)
• Example: "Execute when a reply is received from customer@example.com regarding Case X"
• AI analysis: REDA AI can analyse the reply content (using the configured AI Analysis Prompt) to decide whether to execute or skip the action

Scheduled Action Record Fields

Accessing Scheduled Actions

From the Scheduled Actions List View

1. Open the REDA AI app — Click the App Launcher and select REDA AI.
2. Click the "More" menu — In the REDA AI navigation, click More (three dots) to reveal additional tabs.
3. Select "Scheduled Actions" — The list view shows all scheduled actions in your org, ordered by trigger time or status.
4. Review the list — Columns include Conversation, Status, Trigger Time, Action Type, and Error Message (if failed).
5. Click an action to open it — The action record shows full details and execution history.

From a Conversation Record

When you open a conversation record, a Related Scheduled Actions section shows any actions created during that conversation. Click one to view it.

Understanding Scheduled Action Statuses

Conditional Execution

A scheduled action can carry a condition that is checked again at the moment it fires — not when it was scheduled. This is what stops an action going ahead once the situation has moved on: “only send the follow-up if they still haven’t replied”, “only apply this if the record hasn’t already been closed”. If the condition is not met, the action is Skipped and the reason is recorded on it.

How a condition is built

A condition is a simple comparison against one field on the action’s context record. It is made of three parts, and it is not a query or a formula:

The action must also have a context record (a record Id and its object) for the condition to read. Without one there is nothing to check against, and the action will be skipped rather than run unchecked.

The comparisons available

These are literal values. Type them exactly as shown — they are not translated in any language, and anything else is rejected when the action is scheduled, with a message naming the supported values.

A worked example

An agent schedules an automatic follow-up for two days’ time, but only if the opportunity has not already been closed. On the scheduled action it sets the context record to that Opportunity, then:

• Condition Field: StageName
• Condition Operator: not_equals
• Condition Value: Closed Won

Two days later the job re-reads StageName. If it still isn’t Closed Won, the follow-up sends. If somebody closed the deal in the meantime, the action is Skipped and the record says why.

When a condition cannot be checked

A condition exists to stop an action, so if it cannot be evaluated the action does not go ahead. It is Skipped, with the reason recorded, in each of these cases:

• The operator is not one of the six above.
• The field or object no longer exists — typically because it was renamed or deleted after the action was scheduled.
• A condition was set but the action has no context record to check it against.
• The context record itself has been deleted.

If the check fails because of a temporary error rather than a broken condition, the action is retried instead, and only reported once it has run out of retries. Conditions are honoured the same way whether the action fires on a schedule or in response to an email reply.

Conditions are optional. With no condition set, the action always executes.

Grouped Actions and Cancellation

Related scheduled actions can be grouped so that when one succeeds, the others are automatically cancelled. This prevents duplicate actions:

Example Use Case

A user schedules two follow-up actions:

1. Action A: "Send email reminder if no response in 3 days"
2. Action B: "Send email reminder if no response in 5 days"

Both are assigned the same group key. If the customer replies within 3 days and Action A executes, Action B is automatically cancelled — no second email is sent.

How It Works

• When an action in a group executes successfully, REDA AI finds all other pending actions with the same group key
• Those actions are marked as Skipped (or Cancelled) and do not execute
• This prevents redundant or conflicting actions

Retry Logic for Failed Actions

When a scheduled action fails — a Salesforce API error, missing data, a permission problem — REDA AI retries it, and the mechanism is simpler than it sounds:

• Retry count: up to 3 attempts in total. The Retry Count field on the record shows how many have been made.
• How a retry happens: the failure increments Retry Count and sets the status back to Pending. The action is then picked up again by the next sweep of the batch job — within 15 minutes, since the job runs at :00, :15, :30 and :45.
• There is no back-off. Retries are not spaced out at increasing intervals, so a consistently failing action exhausts all three attempts inside roughly 45 minutes, not over days.
• After the third failure: the status becomes Failed and stops. REDA AI writes an Incident Log carrying the full context — action name, type, description, object, record, retry count and scheduled time — so you do not have to reconstruct it from the record alone.

Because the window is short, Failed usually means a real configuration problem rather than a transient blip — the transient ones tend to clear on the second attempt a quarter of an hour later.

Batch Job Processing

REDA AI runs a scheduled batch job every 15 minutes — four cron entries at :00, :15, :30 and :45 — that processes pending scheduled actions:

Time-Based Actions

• The batch checks all Pending time-based actions
• If an action's trigger time has passed, the batch attempts to execute it
• If execution succeeds the status becomes Executed. If it fails, the status goes back to Pending for another attempt, and only becomes Failed after the third

Email-Reply Actions

• The batch monitors email addresses for replies
• When a reply is detected, the batch immediately processes the action (without waiting for the next scheduled run)
• If an AI Analysis Prompt is set, the AI analyses the reply before deciding whether to execute

Clearer email, record and scheduled actions

Email actions distinguish a Contact or Lead recipient from the related business record, support To/Cc lists, and check the supported recipient opt-out cases. Contact/Lead values supplied as related records are handled as recipients instead of invalid activity links. Record confirmations surface fields that were not applied, rather than silently implying success. Plan steps are reconciled one-to-one; relative scheduled times retain UTC correctly. Disabled agents and disallowed nested actions are checked before confirmed execution. File-link confirmation reuses the supported access-aware path. New Pending or rescheduled time-based actions require a runnable scheduled processor; email-reply tracking and ordinary history/status updates remain valid. Delayed jobs run as their scheduler owner, not by impersonating the requestor. Host guidance reduces duplicate use of another email/calendar connector; it cannot guarantee the host's behaviour.

Frequently Asked Questions