Scheduled work lives in Analyst mode. You describe the outcome and timing, and Upfyn records the recurring job with its hosted Temporal service.

Temporal is the coordinator, not a replacement computer. When a run needs a local folder, desktop app, signed-in browser or device tool, the paired desktop performs that work.

flowchart LR
  A[Temporal schedule] --> B{Desktop connected?}
  B -- Yes --> C[Analyst loads the job]
  C --> D[Use approved files and tools]
  D --> E[Write the result]
  E --> F[Record the run]
  B -- No --> G[Local work cannot execute yet]

What the schedule stores

A useful schedule needs more than a time. Give it the intended result, the source it may use, where output belongs and which actions still require approval.

For example, “Every weekday at 8:00, read new files in this folder and write a short exceptions report to output” is clearer than “check the folder every morning.”

If a connected service is involved, authorize that connector first and confirm its tools are available in the chat. If the job uses local resources, keep the desktop running and connected when it is due.

What not to assume

A schedule does not move your local project into a hosted worker. It also cannot operate a computer that is powered off. The hosted service preserves and dispatches the schedule; the desktop supplies the local execution authority.

That split is deliberate. Recurrence can be durable without turning your machine, files and tools into a cloud workspace.

Design the job before the clock

Scheduling a poorly defined instruction only creates the same ambiguity more reliably. Before choosing a time, run the task once in an ordinary Analyst chat. Check that the inputs are stable, the output has a clear location and the assistant knows how to report uncertainty.

A robust scheduled instruction usually answers five questions:

  1. What starts the work: a time, a weekday or another supported event?
  2. Which local folder or connected service contains the source?
  3. What should be produced, and where should it be written?
  4. Which conditions count as an exception?
  5. Which external actions must wait for approval?

This is more useful than a long prompt full of tone instructions. Recurring work fails at boundaries—missing files, expired authorization, a renamed column—not because the report used the wrong adjective.

The desktop check is a product boundary

When the scheduled time arrives, Temporal can identify the job and coordinate its state. The desktop supplies the environment that contains local files, installed applications and signed-in browser sessions. If that machine is unavailable, Upfyn should show that local execution could not proceed instead of pretending a cloud copy completed it.

This also means that “always on” is the wrong promise. The schedule is durable; the local action depends on the machine. Users can keep an appropriate desktop available for important jobs, but the product should never imply that a sleeping laptop was secretly executing work elsewhere.

For jobs that only call a connected cloud service, availability can differ depending on the tool and the configured execution path. Treat the job definition as the authority: if it names local resources, plan for the desktop to be connected.

Approvals belong near the consequence

Not every step deserves the same approval. Reading a known folder and writing a report under output is different from sending an email, submitting a form or changing a remote record.

Write the schedule so preparation and irreversible action are separate. A morning inbox job can read messages, classify them and draft replies automatically while leaving “send” for a person. A weekly finance job can prepare an exceptions table without approving payments. This keeps the recurring part useful without widening authority merely because the job runs unattended.

Connector permissions still apply. If a connector is set to ask, the scheduled job may pause when it reaches that tool. If authorization expires, the run should identify the missing connection rather than silently omitting that source.

Results need a stable home

Choose an output convention that makes runs comparable. A useful pattern is one folder per scheduled job and one dated result per run, plus a small current summary if needed. Avoid overwriting the only copy unless that is explicitly the intended behavior.

The result should include the period covered, sources examined, exceptions found and actions not taken. That makes the output understandable even when you open it days later or ask a new chat to compare several runs.

If the job produces a document for people to read, Artifact can help turn the raw result into a clearer brief. If it produces data for further work, keep the machine-readable form beside the human summary.

Test failure, not only success

Before trusting a schedule, try one controlled failure: temporarily point it at an empty sample folder, remove a nonessential test file or disable a test connector. The desired response is an explicit, inspectable failure—not a plausible-looking report built from incomplete input.

Then restore the source and run again. This tells you how the workflow behaves when Monday is different from the day you designed it. Durable scheduling is not the absence of failure; it is the ability to see what happened, correct the condition and continue without guessing.

A practical starting pattern

Begin with a preparation job. Ask Analyst to collect, compare and write a result under output, with no external writes. Let it run a few times. Once the inputs and exceptions are predictable, decide whether any next action should be automated or remain a review step.

That progression preserves the advantage of a local execution engine: the assistant can reach the real work while your authority remains explicit.

Ask Upfyn

Turn this repeated job into a schedule. First list the inputs, output location, desktop requirements and approvals. Do not create it until I confirm the plan.