Scheduled Tasks | Alephant Documentation

Scheduled tasks let users run configured agents once or on a recurring schedule. They are useful for daily reports, weekly summaries, customer briefings, knowledge checks, operational monitoring, competitor tracking, ticket reviews, and repeated analysis.

Scheduled tasks are not a way to bypass access controls. Each run creates a new private agent chat, uses the task creator’s accessible agent configuration, model, knowledge, and authorized actions, then writes the result to task history and the selected delivery channels.

The diagram shows the full scheduled task chain: users create a task, AIvis validates identity, workspace, agent, and delivery configuration in the trusted control plane, the scheduler triggers due work, each run starts a new private agent chat, and retrieval, action calls, model calls, delivery, and audit are handled through controlled services.

Availability

The scheduled tasks entry is typically available from the AIvis app sidebar and can also be started from agent-related surfaces. The page and API are available only when the deployment has enabled this capability; otherwise users cannot enter the creation flow.

Before enabling it, confirm that:

Background scheduling and task execution services are running.
At least one agent is accessible to the current user.
The selected agent’s model, knowledge, connectors, and actions are configured.
Email delivery is configured by an administrator if email results are required; webhook delivery accepts HTTPS URLs only.

What a Task Contains

Setting	Description
Task name	Identifies the task in lists and history. Use a name that includes the business purpose and frequency.
Agent	Only agents accessible to the current user can be selected. Each run uses that agent’s latest configuration.
Instructions	The starting prompt for every new run. Make the input scope, output format, and failure behavior explicit.
Schedule	Supports one-time runs and recurring runs. Recurring runs can use common daily/weekly options or a five-field cron expression.
Timezone	One-time tasks use the browser timezone to capture the exact UTC offset. Recurring tasks require an IANA timezone.
Initial status	Create the task as active or paused. Paused tasks do not trigger on schedule, but their configuration is retained.
Result delivery	Supports in-app notifications, email, and webhook delivery. At least one delivery channel is required.

Task Lifecycle

Stage	Behavior
Create	Save the name, agent, instructions, delivery channels, and schedule.
Trigger	The task is queued when its scheduled time arrives. It can also be started manually with Run now.
Execute	Each run creates a new private chat and moves from queued/running into delivery or a terminal status.
Pause or resume	Paused tasks stop scheduled triggers. Resuming recalculates the next run from the saved schedule.
Edit	Update name, instructions, agent, schedule, status, and delivery channels. Edits are checked for concurrent changes.
Complete	One-time tasks become completed after they run. Changing the schedule can make them runnable again.
Delete	Deleting a task stops future triggers. Historical visibility depends on the deployment’s retention policy.

Security Boundaries

Scheduled tasks are designed for unattended execution, so their security boundaries should be explicit:

A task does not grant new access to models, knowledge bases, connectors, or actions.
Users can only select agents they are allowed to access; inaccessible agents are not selectable.
If an agent is deleted, disabled, or no longer accessible, the task shows an unavailable reason and cannot continue running.
Each run inherits only the necessary context and does not automatically read documents, secrets, or external systems outside the authorized scope.
High-impact actions should still be controlled by action permissions, connector authorization, and approval policies; unmet conditions can make a run fail, skip, or wait for user action.
Webhook delivery requires HTTPS and cannot include usernames or passwords in the URL.

Delivery and History

Scheduled tasks support multiple delivery channels. A run’s success depends on both agent execution and whether every selected delivery channel accepts the result:

Channel	Use Case	Notes
In-app notification	Default product tracking and result notification.	Recommended for every task.
Email	Daily reports, weekly summaries, monitoring digests, and business-facing result delivery.	Requires administrator email configuration; users see a setup prompt when unavailable.
Webhook	Send results to internal systems, alerting tools, or automation flows.	HTTPS only; receiver failures are reflected in delivery results.

The task detail page shows run history, including trigger source, start/end time, status, summary, error detail, skip reason, delivery result, and linked chat when available. If a run waits for approval, users can open the linked chat to continue.

Operations and Governance

In enterprise environments, include scheduled tasks in governance routines:

Assign a clear owner, output format, and business purpose to high-frequency tasks.
Apply spending limits to tasks that use expensive models, long-context retrieval, or external actions.
Test outbound email, webhook, and business-system actions against low-risk targets first.
Recurring tasks can run for a long time, so periodically review active tasks, recipients, and webhook URLs.
Monitor failures, skips, awaiting-approval states, and delivery failures for critical reports, checks, and alerts.
If task results are used as audit material, retain task history, delivery records, and linked chats.

Verification

Before releasing the capability to a team, verify:

Create a one-time task, select in-app notification, and run it manually.
Create a recurring task and confirm the next run time uses the expected timezone.
Pause and resume the task, confirming it does not trigger while paused and recalculates after resume.
Test an unavailable or unauthorized agent scenario and confirm the task cannot run with expanded permissions.
Configure email delivery, confirm the setup prompt appears when email is unavailable, then verify delivery after configuration.
Configure an HTTPS webhook and confirm both receiver success and receiver failure are recorded.
Review run history and confirm success, failure, skipped, awaiting approval, and error states are traceable.

Troubleshooting

Symptom	Likely Cause	Resolution
Scheduled tasks are not visible	The deployment has not enabled scheduled tasks, or the user lacks basic access.	Ask an administrator to confirm the capability flag and user permissions.
Task creation fails	No accessible agent, empty instructions, invalid schedule, or invalid delivery channel.	Select an accessible agent, complete instructions, and check time, cron, timezone, and delivery settings.
Email delivery is unavailable or fails	Email service is not configured, or sender/recipient requirements are not met.	Ask an administrator to configure email and validate it with a test task.
Webhook is rejected	URL is not HTTPS, includes username/password, or the receiver returns an error.	Use a credential-free HTTPS URL and inspect receiver logs.
Task is skipped	A prior run is still in flight, or the capability is unavailable at runtime.	Review the skip reason, reduce frequency if needed, and check background services.
Run waits for approval	The task triggered an action that requires user confirmation.	Open the linked chat to approve or adjust the agent/action policy.
Run fails without a result	Model, knowledge, connector, external system, or delivery channel failed.	Use run history error details and inspect the corresponding dependency.