Reminders for overdue work, and what Appdor does and does not automate
Most small teams chase overdue work the same way: someone opens the sheet on Monday, scans the due-date column, and sends messages. The scan is the part worth removing. Two separate things are involved, though, and it helps to keep them apart. One is making lateness visible. The other is pushing a message to a person. Appdor does both, with different tools, and the second is more limited than the word "automation" suggests.
Making lateness visible
The simplest overdue signal is a formula field. The project tracker template has a column called Overdue that is computed from the due date and the progress: a task shows a warning label when its due date is before today and its progress is below complete, and nothing otherwise. The accounts payable template goes further with a Days overdue column, which counts days past the due date for any bill whose status is not Paid, and an Overdue? flag beside it.
A formula only answers the question for each row. To see all the late rows together you want a saved view. The accounts payable template ships one called Unpaid & overdue, which filters the status to Unpaid or Overdue. It is an ordinary saved view, so anyone who can edit the table can adjust it unless its author has locked it.
For individuals there is My work on the home screen. It lists records assigned to you and offers two filters, Overdue and Due in 7 days. A record whose status means it is finished leaves the list. A date-only deadline stays live for the whole of its local day and becomes overdue the following day, while a deadline with a time becomes overdue at that exact moment. A record with an unreadable date is kept in the list as unscheduled rather than dropped, so a bad date does not hide the assignment.
None of this sends anything. A person has to open the app.
Pushing a message
Messages come from workflows. A workflow is a trigger plus steps, built in a visual builder; the Workflows page lists every rule in the workspace, what it runs on and how it last went. Two kinds of trigger matter for overdue work.
The first is a change to a record. A table-change trigger can watch particular fields and carry a filter, so a rule can fire when a status is changed to a late value. This is event-driven, and it needs someone or something to make the change.
The second is a schedule. The schedule editor offers daily, weekly on selected weekdays, or a custom cron expression, with a time zone, and it shows the next run times in that zone so you can check them. It also asks what should happen after downtime: skip missed runs, run once to catch up, or catch up every missed run.
For the message itself, the builder has a Send a notification step and a Send an email step. The notification's recipient can be a user or a list of users, and when it is left blank it goes to the workflow owner. Email depends on the deployment having a mail provider; the recipe gallery lists the email recipes as disabled, with a reason, when it does not, rather than hiding them.
What the templates actually do
This is the place to be careful. Several templates ship a scheduled rule that is named for an overdue check: a daily overdue-checkout digest in the asset inventory, a daily overdue-RFI check in the construction tracker, and a daily deadline sweep in bid management. Each is a daily schedule with a single notification step carrying a fixed message, for example "Some RFIs are past their response deadline".
That is a reminder to go and look, not a list of the late items. The rule does not select the overdue rows and put them in the message. It tells the owner to open the table, where the overdue column and the saved view show the detail. For many teams that is enough, and it is honest to say so.
The builder does have the parts to go further: a Find records step, an If / else step and a For each loop, so a rule can read records and notify per record. Find records takes a simple filter on field values or the same kind of filter a view uses. We would not assume that a comparison against today's date works there without testing it. The builder gives you a Dry run and a Test input selector for exactly this, and Run now performs real effects, so use the dry run first. A reminder rule based on a stored status that someone sets, rather than a computed date, is the safer first build.
Keeping it quiet
Reminders that fail silently or fire constantly get ignored. Each saved workflow has a Failure protection panel: the workflow's author is notified of failures, repeated alerts are grouped, and automatic suspension after a run of consecutive failures is an opt-in setting. The run history shows each run with its recorded input and steps, so you can see why a reminder did or did not go out. Workspaces also have monthly and per-minute execution budgets, and runs over budget are refused rather than queued.
A practical start: open a template that already has the formula and the view, read its daily rule on the Workflows page, and decide whether a reminder to look is enough before building anything more elaborate.