Recurring Nash tasks

Recurring Nash is a limited preview. Your organization must enable it and grant you scheduling and delivery access. Discover the tools available in your current conversation; their presence is not a guarantee that a particular integration or destination is permitted.

Schedule from Nash

For example:

Send me every morning the sales per region as a simple text table in Slack.

Nash needs to resolve what sales means, the reporting period and data source, the local time and timezone, and the Slack destination. It can reuse choices already established in the conversation. Schedules support cron expressions and Slack text, without file attachments. Existing Slack Webhook integrations use their configured destination and need no separate bot token or channel selection. Slack app connections use a specifically authorized channel. After saving, Nash can report the next run as an explicit local date and time, including its timezone.

A task saves the agreed instruction so it can run after the browser closes. It runs with your current Astrato data and integration permissions. A saved Business Question is optional. Scheduling requires a server-stored chat that you own. New chats in the lobby and SLE use this storage by default; see Nash conversations. Browser-stored private chats do not support scheduling. A server-stored chat with private visibility can support scheduling; storage and visibility are different settings.

Flexible schedules

Describe the cadence in conversation or supply a cron expression with an IANA timezone. The minimum interval is one minute. For example:

Cron expression	Cadence in your selected timezone
*/15 9-17 * * MON-FRI	Every 15 minutes during hours 09 through 17 on weekdays
0 8 L * *	At 08:00 on the last day of each month
0 8 * * MON#2	At 08:00 on the second Monday of each month

Five-field cron supports lists, ranges, steps, month and weekday names, L and #. Aliases such as @hourly are accepted. Six fields are allowed when the seconds field resolves to one fixed value; sub-minute schedules are rejected. Randomized H fields and Quartz year/W extensions are unavailable. When both day-of-month and day-of-week are restricted, either can match, following standard cron OR semantics. Nash reports the next resolved local run time so you can check the intended cadence.

A task never admits another occurrence while its current run remains active, including after Slack accepts the message while Nash finishes. Times that become due during that run are skipped. When it finishes, the task resumes at the next future cron time using its current instruction version.

Change the task in the same conversation

Beside region, also include product category in that table.

Nash updates the existing task and identifies its new active version. The previous metric, reporting period, time and destination remain part of the instruction unless you change them. An occurrence already in progress uses the version it started with. Asking about an earlier result does not by itself change the recurring instruction.

Ask Nash to list your tasks, show a task’s recent run history, or pause/resume a task. An administrator-disabled task cannot be resumed by its owner.

Task context and retained observations

Each saved version appears in the chat as a schedule card marked Pinned task, with the complete instruction. Every run uses that version while consulting earlier messages in the same chat. A later exploratory question does not change the task; ask Nash to adjust the recurring instruction when you want future runs to behave differently.

You can request a comparison that remembers previous results:

Every morning, send sales per region to Slack. Compare with the last complete observation and retain today’s values in this chat for the next run.

Nash can retain one small observation per run as a readable table, with its period, units, filters and completeness. Exact observation values remain retrievable when older conversation content is summarized. You can also identify an earlier message as the comparison baseline. State whether you mean the previous observation, an initial baseline, or a fresh query of an earlier period.

A missing baseline means comparison is unavailable. Partial observations cannot serve as complete baselines. Changes to the instruction, data sources or reporting timezone make earlier observations incompatible; establish a new baseline for the changed task. Renaming a task does not do this. Deleting an observation message removes its retained values. Deleting the source chat or pinned task message prevents the scheduled execution from proceeding.

An observation can be retained even if Slack delivery fails. It is never used to replay that failed send. This feature supports small analytical tables, not file attachments or large dataset storage.

Tools for scheduled execution

During a scheduled run, Nash can read earlier messages and this task’s retained observations in the source chat, and record a new observation. These capabilities are available only during scheduled runs, not through external MCP or an ordinary chat, and they do not expand the task’s data or integration permissions.

Understand delivery outcomes

Slack acceptance means Slack acknowledged the message, not that a person read it. A delivery that fails is not resent later. If Slack might have accepted a message before the connection failed, history reports an unknown outcome; do not automatically send it again.

Cron runs use the selected timezone. A nonexistent daylight-saving time is skipped, and a repeated time runs once. Occurrences more than an hour late are skipped instead of sending old reports. If the task belongs to a saved chat, its operational history includes these skipped occurrences.

Use an external assistant

External assistants cannot create or manage Astrato recurring tasks in this preview. Use the host’s own scheduling feature when available. That host can query Astrato and use either its own messaging integration or an authorized Astrato Slack sender.

If Astrato’s sender is available, astrato_reporting_list_integrations discovers permitted connections/destinations and astrato_reporting_send_slack_text sends text. For a webhook, use the returned destination ID webhook; never supply its URL as a tool argument. OAuth access requires integrations:read for discovery and both integrations:read and messages:send for sending. Scope consent does not grant access to every company integration; central user/group and destination permissions still apply.

If both sending options are available and the user has not chosen one, clarify which integration they intend to use. Never ask them to paste integration credentials, including webhook URLs, into the conversation. Do not claim recurring work is scheduled unless the selected host actually created the schedule.

Administration and current boundaries

In-product tenant administrators can inspect operational activity and disable tasks without gaining access to users’ prompts, results or chat content. The current activity view reports recent run and failure counts. Administrators can manage user/group scheduling grants and exact Slack-destination grants through Nash’s integration-access management tools. Disabling a task records the responsible administrator and time. The owner cannot override it by resuming or editing the task.

These integration permissions apply to Recurring Nash. Workbook actions and report schedules keep their own permission model. Schedules cannot be created from published applications or embeds. Other delivery providers and file exports are unavailable.

Start, pause and end controls

Nash suggests a name and description based on the business question. You can edit both manually. Open the Nash schedules tab under Reporting to find your schedules, filter by status, edit their settings, review runs or open the source chat. Home lists your next three under Upcoming. Eligible server-stored chats also show their schedule cards.

• Starts at sets the earliest start. With cron, the first matching time at or after it is used.
• Paused until resumes automatically; leave it empty to pause indefinitely.
• Ends offers Never, After a number of runs, or At a date and time. A date cutoff prevents new starts; it does not interrupt an already active run. Failed runs count toward a run limit; skips do not.

For “check once in 50 minutes”, Nash creates a schedule that starts at the resolved time and ends after one run. Manually, leave cron empty, set Starts at and choose an end after one run. Alternatively use a cron expression with a limit of one run. Nash reports the resolved next start with its timezone.

Manual date fields use your device timezone, labelled in the editor. Recurrence uses the schedule’s IANA timezone. Editing a schedule does not reset its run count. Completed schedules need both valid future timing/end conditions and an explicit resume before they can run again.

Schedule timezone

If you specify a region or timezone, Nash uses that choice. Otherwise, a new schedule uses your browser’s local IANA timezone, such as Pacific/Auckland. Nash confirms the saved timezone and next run. Regional timezones follow daylight-saving changes; a fixed UTC offset is not a substitute for a region. Nash asks for clarification when a requested region is ambiguous or no browser timezone is available.

The timezone is saved with the schedule. Travelling, changing your browser timezone, or editing the task’s instruction does not change an existing schedule’s timezone. Ask Nash to change it explicitly, or edit the schedule’s timezone yourself.

A run marked Needs input completed without sending a message. Open its source conversation to clarify the task. Editing a completed schedule does not resume it automatically; resume it explicitly after adjusting its timing or run limit.