Appmint Schedule

▶ Play video

Watch on YouTube ↗

Schedule Navigation and Saved Records

Schedule is for actions that should happen at a chosen time, such as changing a record’s status or publishing supported content. It is different from a customer appointment calendar: here you choose the target, the action and when the worker should perform it. Start with a disposable Task so you can see exactly what changed without sending a customer a message. Recurrence and owner-linked message/automation scheduling are optional extensions after that first check.

Cedar & Form wants a disposable internal task to move from new to pending at a chosen time. Schedule stores the instruction, queues timed work and records execution activity. The useful result is the task's changed status. A saved schedule, an entry in the timing queue and a completed run are different observations; this course follows all three before checking the task itself.

Use a training organization and an account that can manage schedules and create/read/update Task records in Database. The queue service and schedule worker must be running for timed execution to occur. First prepare the target through these controls:

1. Expand Database → Data Explorer. In the Collections pane, enter task in Search collections.... On a narrow window, open Collections first. Select Task whose smaller technical name is task; do not choose an AI employee work collection or a workflow definition.
2. Choose Add Record. Enter Name cedar-schedule-check-01, Title Cedar & Form timing check, and Status new. If that name already exists, use an unused suffix such as 02. Leave assignments and workflow linkage empty; this is an isolated scheduling fixture, not an operational process task. Choose Save.
3. Back in the Table view, find the new record. Use Search records... and allow the server search to finish after typing pauses. Inspect the matching rows and page controls, or reopen the newly created record directly when the interface offers it. Search collection names in the left pane only when changing collection; that is separate from searching Task records. Match the exact Name and Title before editing. Choose its Edit action, confirm Title and Status persisted, then Cancel to close without further changes.
4. On the same row, choose Edit Raw JSON. This loads the complete saved record. Find the top-level sk and copy its complete string value without the quotation marks using normal text selection and Copy. The toolbar's Copy to clipboard copies the whole JSON document, not just the ID; if using it, paste into your private training notes and extract only sk. Confirm datatype is task and data.status is new. Choose Cancel without changing the JSON.

Keep the exact ID in your notes to match the resulting record. The current Target records picker selects the task by name.

Actual saved Task: cedar-schedule-check-20261002 is new before scheduling. Use your own unused name; the other rows are unrelated and must not be selected.

Edit Raw JSON reveals the saved identifier and data.status. This test uses sk 6ac063ca412569923b11e6bd; copy your own record’s ID. Close with Cancel without changing the record. A title, the name cedar-schedule-check-01, and the record's sk are three different values. The Database course explains collection and record editing in more depth. The current Schedule target picker selects an existing Task by name. The raw identifier remains useful for independently matching the result; it is no longer necessary to type the identifier to configure the target.

Open AI, IVR, Automation → Schedule through the host application's sidebar. The screen heading is Schedule Management. The registered module route and the implementation's active-route value differ, so use the actual sidebar destination rather than guessing a URL. Record the organization and browser timezone before entering any times. The examples below use future times relative to your practice session.

Concept illustration: the intended sequence is saved instruction → queued work → changed target. The depicted new-to-pending change describes the exercise, not proof that a particular job executed.

Visit Overview, Upcoming, List, Calendar, Runs and Logs. Overview brings together saved schedules, status and activity summaries. List is the detailed saved-record table. Upcoming combines repeatable entries with delayed one-time start and end jobs. Its kinds are Repeats, Runs once and Ends; a repeating entry represents its next occurrence without listing that occurrence twice. Calendar combines saved schedules with delayed jobs. Runs shows execution activities. Logs currently shows database/queue synchronization issues; it is not the chronological run-log view. Run details are opened from Runs.

If a panel reports a failed load, use Refresh and inspect that source again. A failed queue request must not be read as an empty queue. The page loads saved records, recurring jobs, delayed jobs, activity and statistics separately. One successful panel cannot establish that the others loaded. Begin the exercise only after you can identify which sources are available. The one-time Task status exercise below has now been executed locally through the interface, with saved instruction, queued job, completed run and matching target read-back. Recurrence, end actions, recovery mutations and provider-linked alternatives still need their own execution checks.

Observed locally on 2 October 2026: Schedule Management shows Overview, Upcoming, List, Calendar, Runs and Logs and an empty Overview. No schedule was created or executed during this entry check.

Target Records, Actions and Arguments

In Overview choose New Schedule. In the drawer’s Target records area choose Add target, then select Task in Target 1 record type. Open the adjacent Search Task by name… selector and search for the title of the disposable task you created. Select the matching record; confirm the displayed title. The current editor stores the record’s ID for you. Do not paste a task title into a raw ID field or create a second task just to satisfy the picker. If the list is empty, check that Task is the selected record type and that the record was saved in this organization. Remove an unused row with its Remove target button.

Current interface captured on 3 October: selecting Task reveals its record search. No record is selected and this draft was cancelled; it is not a saved or executed schedule.

Enter Cedar & Form — mark test task pending in the title field, whose placeholder is Untitled schedule. Under What it does, choose Action → Update Status. In Target status, select only pending. This writes the task's data status. Update State instead writes its top-level state. Choose the field that the owning module actually uses; changing one is not interchangeable with changing the other.

The picker offers preset chips and Or type a custom value + Enter. If the desired state is a valid custom value, type it and press Enter, then remove any other selected chip. Multiple choices become a comma-separated string in the inspected implementation. They do not mean “move through these states in order.” For an ordinary scalar state/status, select one value and verify the resulting field after execution.

Historical 2 October editor: Update Status and the separate schedule status are shown here. The raw target-ID inputs in this older capture have since been replaced by the name picker shown above. This draft was not saved. The schedule’s stop status is separate from the pending value written to the target.

Use one target for the first test. Add target supports additional records, and Remove removes a row, but the current consumer queries the datatype from the first explicit target for all supplied IDs. Keep all explicit targets in the same datatype. Create separate schedules for different collections. An owner-linked schedule can also load its owner, so avoid listing that same record again as an explicit target; duplicate actions are especially troublesome for sends.

The menu also offers Send, Publish, Unpublish, Delete, Run, Stop and Start. Their meaning depends on the target. Publish/Send has branches for supported broadcasts, social posts, pages/posts and messages. A message can be marked pending for a later delivery worker; this is not immediate delivery proof. Unpublish and Delete affect the referenced records and should be tested only on disposable examples. Run accepts an automation or another schedule; Start and Stop accept another schedule. The current save validator refuses these actions on an ordinary Task. Do not choose them for this Task status exercise. The action called Stop is not the control used to pause this schedule.

For the first exercise keep Update Status and pending. It has a specific observable result and avoids provider setup. Leave the drawer open while configuring its time.

One-Time Schedules and Target Verification

Under When → Run at, enter a time at least five minutes in the future. The input uses the browser's local date and time and stores an ISO timestamp. For example, if the browser is set to America/Chicago and the local clock says 10:00, choose today's 10:05; do not type a UTC time into the local field unless the browser itself uses UTC. Record the displayed local time and its timezone in your training notes.

Leave Repeat without recurrence and Ends on empty. In Status, choose stop before the first save. This intentionally creates a paused record so you can inspect its target before booking work. The editor's initial status new is not a safe draft state: the backend can queue a new schedule as soon as it is saved. The same is true of error and done when resaved; the backend's suspension rule is explicit. Use stop for a schedule that must stay paused.

Actual timing controls: enter your own future Run at, leave recurrence/end empty for the first one-time test, and select stop. This isolated unsaved capture has no target or target-status selected; carry forward the completed target from the previous chapter. The displayed date is capture-specific, not a date to copy. No job was saved or queued.

Choose Save Schedule. Return to Overview, find the title and open Schedule Settings or View Details to reread the target, action, single pending value and future Run at time. Both actions open the editor. If the time has passed while inspecting, move it several minutes ahead and save again. Starting a one-time schedule in the past is refused with Run at is in the past — pick a future time. Saving a stopped record is not proof the queue accepted it.

After Save Schedule with stop selected, the actual card shows stop and Not scheduled. Database 1 and Redis Queue 0 are expected at this paused inspection stage. The play icon is Start Schedule; inspect the target before using it.

Back in Overview choose Start Schedule. Refresh the page, then open List and find the saved record. Record its schedule reference. Check Calendar or the queue indication for the matching one-time work. Open Upcoming and look for its Runs once entry; current Upcoming includes one-time jobs as well as repeats and end actions. Match its title and next time. If the record remains saved but unqueued, use the recovery section before assuming it will fire.

After one Start Schedule action, List shows Active and delayed · 1 job for this record. This is queue acceptance evidence before its due time, not proof of execution.

Click the schedule title in List, then expand Raw record. Compare target.datatype, target.id, start.action and start.actionArgs with the intended Task before waiting. This saved record targets the exact ID captured above.

At the due time, allow the worker to process the job, refresh Runs and open its run detail. Then return to Database → Data Explorer, select Task (task), refresh the table and open the original record with Edit. Its Status should read pending. For an exact readback, open Edit Raw JSON on that row and compare sk with your saved ID and data.status with pending; close with Cancel. Compare the actual target ID, the scheduled time and the activity time. A green schedule/run status alone does not satisfy this exercise: the target must show the expected change.

Observed result: the same sk 6ac063ca412569923b11e6bd now has data.status pending, with modifydate 2026-10-03T02:15:00.033Z. This was read after a fresh Data Explorer navigation; no manual status edit was made after the initial new state. The scheduled one-time update therefore reached its intended record.

A one-time start without an end action is normally marked done after processing, with a last-run value. If a future end action exists, it can remain active until that action is due. Do not run the same exercise twice by simply pressing Start on an already expired timestamp. For a deliberate second test, open the disposable task with Edit, set Status back to new and Save. Pause the schedule, set a new future time, save, inspect and start once.

Recurring Schedules and Time Zones

Create a separate schedule titled Cedar & Form — recurring task check, with the same disposable target and Update Status → pending. Keep Status stop while configuring it. Under Repeat, choose Set up recurrence. The recurrence builder offers Minutes, Daily, Weekly, Monthly, Yearly and Custom, with a readable summary and the generated cron expression.

For a short training test, choose Minutes and Every 5 mins using the 5-minute preset, keeping all intended days enabled. This follows clock boundaries; it does not necessarily wait five full minutes from the save. Inspect the next queued time after starting. For routine morning work choose Daily and enter the time. For weekday work choose Weekly, select Monday through Friday and enter the time; leaving all days unselected does not express a useful weekly schedule. The builder also has Weekdays, Weekends and All shortcuts where shown.

After Minutes → 5 → All, the builder reads Every 5 minutes and the expression */5 * * * *. The draft remains stopped and unsaved. The summary describes the expression; it does not prove a queue entry or its effective timezone.

Monthly chooses a day from 1 through 31 and a time. Choose day 1 for a consistent monthly exercise; day 31 does not exist in every month. Yearly adds a month. Check a leap-day or month-end schedule against an actual next execution rather than assuming it advances to the last day of a shorter month. These are calendar expressions, not “every 30 days” elapsed-duration timers.

Recurring timezone deserves a separate check. The inspected Schedule editor has no timezone selector. The backend accepts a saved cron.timezone or timezone and passes it to the repeatable queue. If neither exists, no timezone is sent to the queue, while next-run calculation in the consumer falls back to UTC. Consequently, the displayed local input or browser timezone does not establish the timezone of a recurring job.

For an existing configured recurrence, open its List detail and expand Raw record to inspect those timezone fields, then compare the queued next timestamp with the intended local occurrence. Ask the platform administrator to confirm the queue's effective timezone when no value exists. Do not activate a timezone-sensitive business recurrence until that check is resolved. For an automation recurrence, the Automation builder has its own explicit timezone configuration and is an alternative described in the final section; it still needs a real next-run test.

Do not use Run at as a future start boundary for a recurrence. Once a cron expression exists, this editor marks the schedule as cron and the inspected queue handler does not pass Run at as its starting boundary. To defer a recurring schedule, keep it stopped until the intended start or use a separately verified scheduling mechanism. Remove recurrence clears the expression and changes the editor back to a simple schedule; then supply a valid future Run at before starting.

Check the saved expression, then the actual recurrence

Complete the end settings before the final recurrence check. Select All, confirm the summary has no weekday restriction, save stopped and reopen the editor. In the local replay, changing other fields after All initially saved weekdays instead; the readback caught it before activation. Selecting All again as the final timing edit and saving produced the intended expression. If your reopened expression differs, keep the schedule stopped and correct it rather than starting the wrong days.

For a short controlled replay we entered 1 in Every, which produced */1 * * * *. Upcoming showed the named Repeats job after Start. Minute boundaries are convenient for testing; choose your real operating interval after verification. This row has no timezone badge and does not prove the timezone of a daily schedule.

The same Task has pending status and modifydate 05:30:00.186 UTC, after the earlier manual Run now at 05:19. We did not edit the Task during this interval. Open Raw JSON to compare identity and time, then Cancel; it is an inspection step, not a request to rewrite JSON.

Custom Cron and End Actions

Use Repeat → Custom when the preset controls cannot express the required timing. The input example is 0 9 * * MON-FRI. Its five fields mean minute, hour, day of month, month and day of week. With an independently verified timezone, this example requests 09:00 Monday through Friday. */15 * * * * requests quarter-hour clock boundaries. Enter one expression and inspect the builder's summary before saving; a displayed string alone is not proof that the worker accepted it.

Keep the test stopped while changing the expression, save and reopen it, then start and inspect Upcoming for the actual next occurrence. Compare that next timestamp with your intended local time and timezone. If the recurrence disappears or no job is booked, return to a simple preset, save while paused and retry a controlled test. An invalid cron expression can leave a saved record without a usable repeat job because schedule synchronization errors are logged separately from the save.

Ends on can limit the recurrence and can also schedule a second action. For a separate disposable test, choose a future end time after at least one intended occurrence. When the field is populated, When it ends appears.

Custom accepts the cron string. Filling Ends on reveals a separate When it ends action picker; it is still unselected in this actual draft. Complete the intended end action below before saving. The capture date is illustrative; no recurrence or end job was scheduled. Choose Update Status, type done in Or type a custom value + Enter, press Enter and keep only that chip. The expected observations are the task's pending status after a recurring occurrence, followed by done after the end job, and no later recurrence. Check all three; an end time displayed in the form is not evidence that the end job was queued or that future jobs stopped.

For a one-time publish window, a supported disposable page/post can use Publish at Run at and Unpublish at Ends on. Verify the target through its real viewing surface before, during and after the window. This alternative needs a suitable content record and permission to publish it; the Task example cannot prove publishing. Set the end strictly after the start. For cron, an end already in the past prevents a repeat schedule from being created. Clear the end date with its clear control to remove the associated date, action and arguments together.

Use end actions deliberately. Ending recurrence and changing a business record are separate intentions. If only a stop boundary is required, verify that boundary with the queue; do not add a Delete or Unpublish action merely to make the form look complete. To halt practice immediately, use Overview's Stop Schedule and read back the result.

Verify the end result separately

This saved example repeats pending and requests done at Ends on. Scroll inside the drawer to reach the end action, its selected value, Status and Save Schedule. The capture shows the fixture after it was stopped for cleanup; use a future date for your own test.

Before the due time, Upcoming contained both Repeats and Ends for this same title. One queued entry does not stand in for the other.

Observed limitation: in the local test, the end and a minute recurrence shared the same boundary. The schedule became done, but the Task still read pending rather than the requested done. Upcoming also retained an overdue Repeats entry. No later target modification occurred during the following minute, and Stop Schedule removed the remaining entry. The end-action outcome therefore failed this replay; do not rely on the green schedule status to confirm it.

The exact Task remained pending with modifydate 05:32:00.177 UTC, the end boundary. This screenshot documents the mismatch, not a successful completion. If you see this, stop the schedule, inspect the owning record, and report the schedule ID, target ID, expression, end time and expected end value. Do not repeatedly start it or assume a different end time is a verified fix.

Local repair replay: check the record as well as the schedule

The same exact-minute failure was repaired locally on 4 October. In a new controlled replay, the minute worker changed the disposable Task to pending at 16:46 and 16:47 UTC. At the configured end, 16:48 UTC, the end action changed it to done. A later read at 16:49:14 still showed done with the same 16:48 modification time; the named repeat was absent from Upcoming. The fixture end date and Start were set through the local API for this regression check, so this is result evidence rather than another recorded UI-authoring sequence.

After Refresh, the exact course schedule shows done, its final run at 11:48 AM America/Chicago, and no next run. This confirms the schedule state; inspect the target separately.

Open Database → Data Explorer, select Task, and match the recorded task name and ID. Open Edit on the matched row and maximize the form. The saved Name, Title and Done status are readable together; use Cancel to leave without editing. The Completed field is empty in this capture, so this result proves the status change, not completion-metadata population.

The repair prevents a recurrence starting at or after its saved end from overwriting the ending action, and removes repeat metadata. An action that starts before the deadline and is still running when the end action fires remains an unresolved concurrency case. Keep that limitation in mind for long-running integrations; this short local status-update replay does not establish their ordering. The earlier failure screenshots remain dated diagnostic evidence, not the current result of this repaired test.

Search, Calendar, Pause and Resume

In Overview search for Cedar & Form and use All Status, Active, Paused, Completed or Failed to narrow the cards. Displayed status names translate stored values, such as stop to paused and done to completed. If a record disappears after a transition, clear the filter before recreating it.

Open List for a more detailed search. It can match the title/name, owner datatype or ID, and start action. Inspect the columns Schedule, Type, Runs, Action, Status, Redis and Updated. The Runs from and Runs to filters apply to the saved start date, not the history of every recurring occurrence. Clear those date filters if a cron record with no start date seems missing. Open a row to inspect its reference, status, timing, action, queue status and Raw record.

List exposes its own status/type/date/search controls. This loaded local organization has zero schedules; no row details or saved pause/resume result are established by this capture.

Calendar helps compare timing visually. It combines saved records and delayed queue jobs, including saved-only and queue-only entries. Read the entry's queue description and correlate its schedule reference; a calendar marker does not by itself prove execution. Likewise, the List Redis label ran can be inferred from a start date in the past. It is not a worker receipt and cannot replace Runs plus target readback.

Calendar separates saved-only and queued counts above the dates. This empty October view contains no scheduled execution; use the month arrows/Today and All or Scheduled controls to inspect the intended period once a record exists.

Pause the recurring practice schedule from Overview with Stop Schedule. Refresh and reopen its settings to confirm Status stop. Inspect the repeatable queue and next-run views for the change. Wait beyond its previously expected next occurrence, then check Runs and the actual target for new work. A job already executing at the moment of pause needs its own result inspection; do not infer that a pause reverses a completed target update.

To resume, choose Start Schedule, refresh and verify a new next occurrence. For a one-time schedule, edit its date into the future before resuming. Delete Schedule asks for confirmation and removes the schedule record; use it only for a completed disposable exercise after preserving the reference and results. Deleting the instruction is separate from undoing the target's previous change.

Run now, Start and Stop do different jobs

For a single controlled recheck, keep the task-only example stopped, confirm its target ID and Update Status value, then choose Run now once. Wait for the new execution, match its time and inspect the target. This deliberately executes even when the schedule is stopped; stopped describes its automatic timing. Use Start Schedule only when you want timed execution to resume. The local replay below used a newly created task with initial status new and a stopped schedule. After one Run now, the schedule remained stop while the task became pending.

The lightning icon is Run now; the play icon starts automatic timing, and the pause icon stops it. Last Run changed after the manual execution, while Next Run remained Never. This is the actual disposable course schedule, not a system maintenance job.

Return to Data Explorer → Task, locate the original record and choose Edit. Maximize the editor using its top-right Maximize control when labels or values are clipped. Match its Name and Title, read Pending, then Cancel without changing it. The pending value here was written by Run now, not manually entered in this editor.

To check Stop safely, give the same task-only schedule a future Run at, save stopped, and choose Start Schedule. Open Upcoming and identify its named Runs once entry. Return to Overview and choose Stop Schedule on that exact card. Reopen Upcoming: its entry should disappear, while Overview reads stop. In the local replay, the named entry disappeared after Stop and the task stayed pending; Stop did not reverse the earlier manual execution.

Cancel a queued occurrence deliberately

Current queue view, 3 October. The shown jobs belong to existing system maintenance schedules, not the disposable course fixture. They were inspected only; do not cancel a system job to practise the procedure.

In Upcoming, identify the schedule title, job identifier, time and kind before choosing Cancel Schedule. Runs once, Repeats and Ends are different jobs. Cancelling a schedule’s start or repeating entry sets the saved schedule to cancelled and removes its scheduled jobs. Cancelling only an Ends entry removes that end job; it does not cancel the rest of the schedule or rewrite the saved end settings. A later save can recreate the end job from those settings, so change the saved end configuration as well when the intention is permanent.

Refresh Upcoming and Overview and check both the missing queue entry and saved status. If the row reports That job is no longer queued — it may have already run, inspect Runs and the target before taking another action. For a repeat, cancel its Repeats entry; the server refuses cancellation of an individual generated occurrence. The one-time start cancellation was replayed locally: Start queued the disposable course schedule, Cancel Schedule removed that named job, and Overview changed to cancelled. No confirmation dialog appeared in this replay, so identify the correct row before clicking the red X.

This is the actual future job before cancellation. Match the full course schedule title and Runs once label. The red X at its far right is Cancel Schedule; the neighbouring document icon is View Logs.

After cancellation, this card reads cancelled and Not scheduled. The task’s earlier pending result is retained. Repeating-job cancellation and cancellation of an Ends entry still require their own runtime verification; the one-time result does not establish those alternatives.

Upcoming’s View Logs button still does not open run details in the current implementation. Open Runs and select the matching execution there. The earlier course warning that Cancel Schedule only displayed a notice is obsolete: cancellation now calls the schedule-control service.

Run Details and Business-Record Verification

Open Runs after the controlled one-time or recurring test. Find the matching schedule and time, then inspect Status, Start Time and Duration. Choose View Logs for the run or View Error for a failed entry. The detail dialog can show the schedule name, status, time, error or log text; it may explicitly have no additional text. Use Close to return. Record the actual reference and timestamp so a similarly named earlier test is not mistaken for this one.

Actual run at 21:15 local time: the row is completed and references schedule 6ac06416412569923b11e6c8. Database retains the instruction while Redis Queue has returned to zero. Duration is N/A, so do not infer a measured duration from this view.

View Logs opens this run’s detail. Its text repeats “Schedule started,” despite completed status; it does not describe the target’s final value. That is why the separate Task read-back is required.

Open Runs to inspect execution activity. Here no runs exist, so View Logs/View Error cannot yet be demonstrated. A populated run detail and the exact changed target remain required evidence; this empty page is not a successful run.

For the Task exercise, return to Database → Data Explorer → Task, refresh, and open the exact task with Edit. Read its Status and, in Edit Raw JSON, data.status, rather than relying on a success notice or stale editor value. For an Update State alternative, inspect the top-level state instead. If two runs occurred close together, compare activity and last-updated information; a final pending value alone cannot establish that only one run occurred.

Some supported actions hand work to another service. Send on a message can put it into a pending state; check its later delivery status and the controlled recipient inbox. A broadcast or social post requires its own provider/task result. Run on an automation emits an event and needs an Automation execution inspection. The schedule's completed activity is evidence that its worker path completed, not a blanket guarantee that every downstream business operation succeeded.

The current consumer can also return without targets when an ID no longer resolves, and several target-specific branches catch and log errors internally. A schedule may therefore show completion without the intended change. When the target is unchanged, check its actual ID, datatype and organization; confirm it still exists; compare the selected action with the target's supported behavior; and inspect worker logs if the run detail has no useful error. Never repair this by repeatedly sending a customer message “to see if it works.” Use a disposable record or controlled recipient and first determine whether the original action occurred.

Complete your test notes with the saved schedule reference, target reference, scheduled and actual times, queue observation, run outcome and final target status. Mark any missing layer as unresolved. This gives an administrator enough information to investigate without guessing which attempt you mean.

Queue Synchronization and Failure Recovery

Open Logs to inspect MongoDB ↔ Redis Sync Issues. The panel separates Missing Redis Entry from Orphaned Redis Entry, with counts for Total Issues, Missing Redis and Orphaned Redis. Use Check Sync to refresh the comparison. Only draw conclusions after both the saved-record and relevant queue requests loaded successfully; the page suppresses some comparisons when inputs fail.

Logs is the saved-record/queue comparison, not call-style execution logs. All systems in sync here compares an empty database and empty queue; it does not prove a scheduled action ran. Check Sync refreshes that comparison.

A missing queue entry means the saved schedule was not found in the compared queue. First inspect whether it should currently be queued. A paused schedule should not execute. A completed one-time schedule may have no future job. A record with a past start date or invalid cron cannot be repaired simply by asserting it is active. Read the saved target, action, timing and status, then correct those values while stopped.

For an intended active schedule with a valid future time, choose its Sync to Redis. The handler rereads and saves the existing record to invoke normal synchronization, then reloads the page data. Check the queue again and inspect the next time. Sync All Missing to Redis repeats this operation across entries; use it only after reviewing each candidate, since resaving can book real actions. Prefer the single Cedar test while learning.

An orphaned queue entry has no matching saved schedule in the comparison. Remove from Redis and Remove All Orphaned currently display an instruction to ask a platform administrator to inspect the queue entry; the inspected handlers do not remove it. Preserve its job identifier and time, then have the administrator examine the canonical schedule and queue. Do not record an orphan as removed because a button was clicked.

If saving succeeds but queuing does not, use the schedule reference to investigate the synchronization worker. The handler cancels old jobs and recreates them on an update, and logs scheduling exceptions separately. A date that became past during editing, a malformed expression or an unavailable queue can leave a valid saved record without the intended job. Correct the cause, move one-time tests safely into the future, resave or sync once, and verify queue readback before waiting again.

If a run fails, open its error, verify whether the target partially changed, and repair the actual cause. There is no general Retry button established in this Schedule UI. For a controlled replay, pause the instruction, inspect the target, set a new future one-time date or correct the recurrence, save and start once. For sends, publish actions or deletes, establish the original result before replaying. A queue worker may already have retried internally; creating another schedule can duplicate work.

Correct the error shown beside the schedule

The current server returns specific validation errors. Work on the same saved instruction instead of creating duplicates:

Do not replace a refused target with another business record simply to clear validation. Run actions target an automation or another schedule; Start and Stop actions target another schedule. These action choices are different from the Overview buttons bearing similar names. A schedule cannot target itself for these control actions.

Owner-Linked Schedules and Automation Alternatives

The concrete owner-linked example is a saved email in CRM → Comm Center → Compose. This is an extension of the Task exercise; it requires an organization mail sender that already passes a controlled delivery test. If that provider has not been configured, keep this branch as a saved draft and complete the Task exercise first. Sender setup and actual inbox delivery remain release requirements for this branch.

Open Comm Center → More → Compose when Compose is not already visible among the top tabs. In Compose, select Channel → Email. Choose your configured address in From, add a controlled address in To and press Enter to make its recipient chip, enter Subject Cedar schedule check 01, and write This message tests the saved schedule connection. in Email body. Choose Save draft, then open Messages, find that subject and open its row. The composer loads the saved message; this persistence step matters because an unsaved composer uses an inline schedule, while a saved message owns a separate schedule record.

Expand Schedule. In the owner-bound manager choose Add schedule. Set title Cedar saved message test, Action Send, a future Run at time and Status stop; choose Create schedule. No explicit Target records row is required because the saved message is the owner. In central Schedule → List, find this schedule and inspect its Raw record: owner.datatype must be message, and owner.id must reference the saved message. Only after checking sender, recipient and body should you Start Schedule once. Follow its queue entry, run and then Comm Center → Messages plus the recipient inbox. Schedule completion alone is not delivery proof.

The unsaved composer also has a Schedule disclosure below Templates in the left column. This is different from the Schedule action in the top toolbar. Expand the disclosure to inspect timing; do not press the toolbar action merely to open the fields.

Current local Compose view: the lower-left Schedule panel exposes an inline action and Run at. No recipient, subject, body or saved message is present, so this is not an owner-linked schedule yet. Save and reopen the intended message first for the owner-bound procedure above. Nothing was sent or scheduled during this capture.

The embedded manager has Upcoming, Past, All and Runs. If an owning surface says Save the parent record first to start managing schedules, save/reopen that record before adding timed work. The concrete UI route above is documented, not a recorded provider outcome. Do not treat editing a parent’s inline schedule and creating a separate owner-bound schedule as the same save operation.

For a scheduled multi-step process, use Automation's Workflow Builder and its Recurring Schedule trigger. Prepare the automation and its real target actions, complete a manual test, and configure the trigger's displayed timing fields. In Recurring Schedule, choose the intended timezone explicitly in that builder, save and activate only after reviewing the actions. Follow its booked schedule in Schedule, then follow the resulting execution in Automation Runs & Logs and inspect the actual output record. For a one-time automation, select Specific Date/Time, enter a future Date and Time, select Timezone, and leave Recurring off. Start creates an automation-owned simple Schedule through the dedicated scheduling service. Recurring on that trigger means the same date every year. The Automation scheduled-trigger procedure gives the complete field/save/start/readback sequence. Both the one-off and annual alternatives still need live execution proof. This cross-module route does not add a timezone selector to the Schedule drawer.

An administrator-created Schedule can also reference an existing automation datatype/ID and use Run; the consumer emits the scheduled-run event for that target. The preferred learner route is the automation's own time-trigger editor because it retains the automation's trigger context. Do not use generic Run on an ordinary Task and expect it to invent a process. Special campaign, workforce and verification schedule actions are created by their owning features and require those feature-specific lessons; do not overwrite their actions with a generic dropdown choice.

Finish by pausing the recurring practice schedule and confirming no further practice work is due. Keep the completed one-time record long enough to compare the run with its target. The reusable procedure is concrete: inspect the instruction, confirm the queue accepted it, inspect the execution and read the business result. When one step is missing, retain the identifiers and resolve that step before expanding the schedule to real business work.