Schedules and automation

Scheduled-trigger types appear in shared contracts, but no dedicated Workflow Agent schedule route, configuration surface, or live scheduler was verified. This page explains the current availability boundary and how to record a scheduling requirement without presenting unsupported setup steps.

Schedules

A schedule would start a workflow according to time-based rules rather than a user action or incoming event. The concept can appear in type definitions used elsewhere in Ethen, but a type is not evidence that Workflow Agent can configure or execute it.

The current product model supports descriptions, app detection, drafts, route analysis, simulations, and preview records. It does not establish a scheduler that wakes a workflow, calculates future occurrences, or invokes external apps.

If your automation requires timing, include the requirement in the workflow description so it remains visible. Mark the trigger as unavailable rather than substituting a manual or webhook trigger without approval.

Current availability

There is no approved Workflow Agent product link for schedules. No inspected page provides a calendar editor, recurrence builder, timezone selector, pause control, next-run display, or schedule history.

This absence should be treated as a product limitation, not as a hidden feature. A scheduled trigger listed in a broader agent runtime contract may describe future or separate runtime behavior; it does not make Workflow Agent schedules live.

Templates and app-pair suggestions also do not change availability. A template can describe a recurring outcome while remaining a draft and simulation starting point.

Configuration

Do not enter or publish recurrence syntax, cron expressions, timezone rules, or retry settings as Workflow Agent instructions. The repository does not verify where such values would be stored or how they would be interpreted.

A draft can capture the business requirement in plain language: frequency, intended timezone, acceptable timing window, and what should happen when the trigger is missed. Keep those details as design inputs. They are not an active schedule.

Before a future schedule could be documented as configurable, implementation evidence would need to show the product route, accepted fields, validation behavior, persistence, editing, enable/disable state, and interaction with approvals and credentials.

Execution boundaries

Even a configured schedule would not by itself prove that the workflow can execute. The app route, credentials, policy, approvals, connector state, and activation capability would still need to be available.

Current Workflow Agent activation is locked. Therefore, a time-based requirement cannot produce a live external write through the verified product. Simulations can model the draft’s downstream steps, but they do not wait for or fire at a scheduled time.

Do not describe missed-run recovery, catch-up behavior, overlap handling, concurrency, or retries. None of those scheduler semantics are sourced.

Monitoring

No schedule-monitoring view is verified. There is no documented next-run timestamp, last-run status, missed-run alert, disabled-schedule list, or durable execution history for Workflow Agent schedules.

The runs page shows local-safe preview records, not schedule executions. Do not reinterpret those entries as proof that a timer fired. If timing is important during design review, track it outside the product until a supported monitoring surface exists.

A future monitor would need to distinguish schedule state from workflow state and show whether a trigger was evaluated, blocked, or executed. That behavior remains unimplemented in the supplied evidence.

Limitations

Schedules are a requirement that Workflow Agent can describe, not a capability it can currently operate. The page remains a draft because availability, configuration, persistence, execution, monitoring, timezone behavior, and failure recovery are unverified.

Keep scheduled workflows in design form. You can still validate the participating apps, steps, route readiness, credential needs, and approval gates through the builder. Stop at simulation and record that the trigger mechanism is unavailable.

Do not invent a schedule URL, copy runtime trigger fields into user instructions, or promise that the feature is merely waiting for activation. Additional implementation evidence is required before this page can become a setup guide.

Timezone and recurrence questions

A usable scheduler would need to define how it handles timezone selection, daylight-saving changes, start dates, recurrence, exclusions, and disabled periods. None of those rules are present in the verified Workflow Agent surface. Do not copy a cron expression or recurrence example from general knowledge and label it supported.

Record the intended business timing in plain language so the requirement can be reviewed later. Include the desired timezone and acceptable delay, but mark them as design inputs.

Missed and overlapping occurrences

Live automation also needs a policy for a trigger that is missed while the service is unavailable and for a second occurrence that arrives before the first finishes. Catch-up, skip, queue, overlap, and cancellation behavior are all unverified. A workflow that depends on one of those semantics cannot be represented faithfully as active.

Relationship to approvals and credentials

A schedule should never be treated as permission to execute. If the downstream action requires approval or a current credential, those gates would still apply on every occurrence according to a defined policy. The present product cannot demonstrate that interaction.

Safe design work today

Use the builder to validate the downstream steps independently of time. Simulate representative inputs, document the desired recurrence, and list the missing scheduler behaviors. This preserves useful work without implying that a timer is running. If the business requires immediate automation, Workflow Agent should not be presented as satisfying that requirement in its current state.

Schedule ownership

A live schedule would need an owner and a clear relationship to the workflow draft. Scheduling evidence does not establish whether schedules would belong to a user, workspace, project, or workflow definition. Do not invent an ownership or permission model.

Editing and disablement

No verified control exists for changing recurrence, pausing a schedule, disabling it temporarily, or deleting it. A type that represents a scheduled trigger does not define those operations. This page should not use common calendar or automation patterns as though Ethen implements them.

Trigger payload

A schedule would also need to define what data enters the first step. Time alone may not supply the record or context a downstream action needs. The current builder can model representative inputs during simulation, but it cannot prove how a scheduler would construct them.

Time-based monitoring gaps

Without a next-run time, last-trigger time, and outcome link, an operator cannot verify that a schedule is functioning. Workflow Agent runs are preview records and must not fill that role. No alert or missed-occurrence mechanism is sourced.

Alternatives during preview

An operator can manually open the draft and request a simulation at the intended time to inspect downstream readiness, but this is a review exercise, not automation. Do not describe manual repetition as a supported schedule.

Publication criteria

This page can become a configuration guide only after route, fields, timezone behavior, recurrence validation, persistence, execution, disablement, monitoring, and error recovery are inspected. Until then, its purpose is to prevent a scheduled-trigger concept from being mistaken for a product capability.

Scheduling and source freshness

A future schedule would run against whatever app, connection, and policy state exists at trigger time. The current preview cannot demonstrate how changes between configuration and execution would be handled. A previously valid simulation therefore cannot stand in for future scheduled readiness.

Disabled schedules versus absent schedules

The repository does not show a schedule object that can be disabled; it shows only trigger concepts in shared contracts. Documentation should say the product surface is unavailable, not that schedules are paused or turned off.

Operational risk

Time-based execution can repeat mistakes automatically. Before any live scheduler is introduced, route, approval, credential, idempotency, and monitoring behavior must be explicit. The present activation lock prevents those unresolved risks from becoming external actions.

Calendar and event sources

A schedule is not the same as a calendar integration. A calendar event could be represented as an app trigger, while a scheduler would generate time-based occurrences itself. Neither live path is verified here. Do not use one concept to imply support for the other.

Activation dependency

Even after a future schedule fires, Workflow Agent would need an executable route. The present product has no verified activation mechanism, so adding a timer contract alone would not make automation live.

Testing a time requirement

During design, choose representative timestamps as simulation inputs and verify how later steps use them. Label those values as test data. The simulator does not wait until the timestamp or prove timezone conversion.

Limit statement

The schedules page intentionally documents absence. It should remain shorter and more direct than a live scheduling manual, while still explaining the missing configuration, execution, and monitoring contracts.

No implied persistence

A schedule concept in a type does not create a stored schedule. There is no verified object to list, edit, disable, or delete.

Relationship to run history

A future scheduler would need to link each occurrence to a resulting execution record. Current preview records do not provide that linkage and should not be labeled scheduled runs.

User-facing wording

Use “not currently available” for configuration and monitoring rather than “temporarily offline,” which would suggest a previously functioning scheduler.

Current conclusion

A scheduling requirement can be documented and simulated as context, but no timer, recurrence object, trigger execution, or monitoring record is available. Keep the workflow draft explicit about that missing mechanism.

No background timer should be inferred from a saved workflow description.