# Scheduled Work Guide

Scheduled Work coordinates reminders, recurring tasks, and data refresh schedules in one place. It is intended for operators who own recurring work and administrators who investigate failures.

## Access

Open **Scheduled Work** at `/automations`. The page shows only actions allowed by the active tenant, role, and capability. Ask a tenant administrator to grant the required schedule or reminder capability; do not reuse another operator's link or credentials.

## Create the shortest successful workflow

### Create a reminder

1. Select **New reminder**.
2. Describe the follow-up, choose the due time and timezone, and confirm the intended workspace.
3. Save it, then verify it appears under **Reminders** with the expected due time.

### Create a recurring schedule

1. Select **New schedule**.
2. Choose the supported task or refresh target, cadence, timezone, and first run.
3. Save it and confirm the schedule is **Active**.
4. Use **Run now** when available and review the latest result before relying on the recurrence.

## Find and operate work

Use **All**, **Schedules**, **Reminders**, and **Recurring syncs** to narrow the list. Search and focus filters help isolate active, paused, failed, or due work.

- **Pause** or **Disable** stops future scheduled runs without deleting history.
- **Enable** resumes future runs after recovery is proven.
- **Run now** starts a supported task immediately; it does not change the cadence.
- **Cancel** prevents an uncompleted reminder from firing.
- **Delete** removes the configured item. Confirm the exact target first because related audit history may remain.

## Security and tenant boundary

Schedules execute only against resources available to their owning tenant and saved scope. They do not expand source, artifact, or credential access. Stored credentials remain secret references; never place raw credentials in a reminder, schedule name, or task instructions.

## Automation and MCP

Topline can propose or create supported scheduled work through approved product workflows. External MCP clients see only tools and resources allowed by their OAuth scopes and tenant capabilities. Review target, cadence, timezone, and mutability before accepting an automated change.

## Errors and recovery

- **Missing action:** verify the active tenant and required capability, then refresh after access changes.
- **Authentication failure:** repair or rotate the referenced credential, test the source, then run once manually.
- **Schema or configuration failure:** update the target configuration before retrying.
- **Rate limit:** wait for the provider retry window; repeated immediate retries can prolong the failure.
- **Repeated failed runs:** pause the schedule, preserve the latest error and last successful run, correct the cause, run a smoke test, then re-enable it.
- **Wrong time:** confirm the schedule timezone and daylight-saving behavior.

## Enablement, smoke check, and rollback

Enable a new schedule only after a bounded manual run succeeds. The smoke check is: correct tenant, correct target, expected result, no secret disclosure, and a visible successful run. Roll back by disabling the schedule or cancelling the reminder; revert the target configuration separately if it was changed.

## Limitations

Reminders are human follow-ups, not a replacement for unattended work that needs idempotency, retries, and operational alerting. Available schedule targets and controls depend on the enabled product profile.