Sort Stack ("Stork" for short)

Summary

Sort Stack is a task management Airtable base with a sorting algorithm designed to help users prioritize their tasks.

Background

Over the course of the five years prior to my Spring 2022 academic term studying Computer Science at university, I had tried and/or studied several to-do list apps, but always ran into problems using them that prompted me to continue my search. By the time my Spring 2022 term rolled around, I was out of options and resorted to throwing together an Airtable base that would at least help me keep track of my homework assignments. However, I kept tinkering with it — using a combination of my programming knowledge and experience using other to-do list apps — until I was satisfied with it, which just so happened to take about 14 months. After I got the base to a point where I was satisfied with it, I figured that if I found this base a more effective way to manage my tasks than anything else on the market, maybe someone else would, as well. If you feel like you've tried practically every to-do list app in existence, this base might be the one to end your search.

Features

Sorting Algorithm

One "feature" of so many to-do list apps that claim to help you prioritize tasks that drives me crazy is the prioritization tiers one. I simply don't see how prompting a user to assign a priority level to a task is supposed to help someone prioritize tasks who struggles to do so. Additionally, factors such as how close a task's deadline is can affect the priority level of a task and yet most, if not all, apps don't support the automatic escalation of a task's priority level based on factors such as the proximity of its deadline. Lastly, the number of priority levels these apps provide is always an arbitrary number. If such an app were to provide the user with three priority levels, who's to say that there shouldn't be more? If you try prioritizing tasks in a tier-based fashion, you'll never fully prioritize your to-do list. It's for this reason that I didn't find prioritization via the Eisenhower Matrix to be effective. Rather than messing around with static prioritization tiers, Sort Stack automatically sorts your to-do list using properties like:

Check-In Time

The time you would next like to "check-in" with a task. This time is intended to be changed frequently, as Sort Stack is designed to be a short-term planning solution. I never jived with the practice of scheduling my tasks over an extended period of time and wanted a task manager that wouldn't penalize me for having an overstuffed to-do list on a given day.

Checkout Time

Essentially a soft deadline. However, unlike a soft deadline, this property is intended to be changed somewhat frequently. You could also use this property to indicate the time a store or office closes. Additionally, this field can only be modified via Anchor and Floaty Events, which was done to discourage the abuse of this field while encouraging the usage of the aforementioned events fields, especially the Floaty Event one.

Deadline

I'll assume everyone knows what that means.

Overdue Deadline

A fallback deadline for overdue tasks. For instance, at an apartment building where I used to live, rent was due on the first of every month, but they wouldn't start pestering those who didn't pay until the fourth of the month. In this scenario, the fourth of each month would be the Overdue Deadline for the paying rent task.

Intention

How much and what kind of progress you expect to make on a task. The three intention types are as follows:

1. Survey: For tasks that you're not sure how to resolve yet. Sessions devoted to tasks with this intention should be spent learning enough about the task to know how to progress towards its resolution.
2. Progress: For tasks whose resolution you know how to progress towards, but that you don't expect to be able to resolve in one session. For example, a task like "Watch Season 1 of Game of Thrones" would likely be assigned this intention at first due to the several hours it would take to complete this task.
3. Resolve: For tasks that you are confident you can resolve within one session. Since the duration of a session is a somewhat abstract concept, Sort Stack aims to demystify it via the Task Resolve Threshold (more on that later).

Note that a task's intention can change while you're working on it. For instance, after surveying a task for a few minutes, you might come to realize it's actually pretty easy to complete and could update its intention to Resolve. The Progress intention has the lowest priority out of the three due to Parkinson's Law. Tasks with this intention are considered the most dangerous because you could find yourself working on such tasks longer than you should. I've caught myself working on tasks that I know how to complete for longer than I should because I was subconsciously avoiding tasks I was less sure of how to complete. The overall goal of this field is to help users refine their lists enough that they have total clarity concerning how to address the tasks on their list, which would be reflected by a Now View that only has tasks with the Resolve intention.

Status

Statuses in Sort Stack can be broken into two categories: Unresolved statuses and resolved ones.

The unresolved statuses are as follows: Todo, Queue, In Progress, and Waiting. I think the Todo and In Progress statuses are pretty self explanatory, but allow me to elaborate on the Queue and Waiting ones.

The Queue status is meant for tasks that you'd like to get around to doing sooner rather than later. You can think of this status like casting a vote for which tasks you'd like to be prioritized over others.

The Waiting status is for tasks with which you cannot proceed until some other process is completed. If the Waiting Anticipated boost is on for a task to which the Waiting status is assigned, this boost is automatically removed, since you're no longer anticipating the waiting. If you change a Waiting task's Check-In Time to one in the future, when it is eventually elapsed and its corresponding task finds its way back into the Now view, said task's Waiting status is removed and a secret "Waited" boost is assigned to it. You should check-in on such tasks to determine whether you need to keep waiting on them and update their statuses accordingly.

The Resolved statuses are as follows: Completed, Dismissed, Cancelled, and Resigned. I assume most people know what the Completed and Cancelled statuses do, but I'll elaborate on the other two statuses.

The Dismissed status is for tasks that you kind of completed. For example, if you had a homework assignment task wherein you were supposed to read a chapter from a book, but you only skimmed it, you could mark this task as Dismissed instead of Completed.

The Resigned status is for tasks that you gave up on. Such tasks that also had the Meaningful boost will appear in the Maybe Later view.

Boosts

Six checkboxes that help refine the prioritization algorithm. The six Boosts are as follows:

1. Quick: For tasks that are expected to take three minutes or less.
2. Urgent: For tasks that should be completed as soon as possible.
3. Waiting Anticipated
4. Health Contributor
5. Deliverable
6. Meaningful

Project Visibility

Consists of three visibility conditions: "Cloudy," "Calm," and "Clear." This feature is for projects and gives you a sense of how well-defined a project is. Ideally, all projects should at least have a "Calm" visibility condition. The way you're expected to primarily better-define projects is by creating predecessor tasks for ones that you're now sure how to resolve. A project with the "Calm" visibility condition is likely one that has been defined well enough for you to define its next waypoint, which you could officially store in said project's "Waypoint" (Name) field. I added the "Calm" visibility condition because I didn't want users to think that they were poorly managing their projects just because they weren't 100% visible. Projects that are "calm" are ones that are considered visible enough by the system.

Telescope

Gives you the ability to "see" your current Scheduling Horizon, a date that's intended to inform you of how many days into the future you should time block, as well as the end date that you assign to a Latitude event (with the start date being whatever you want).

Views

Now and Later

All unresolved tasks can be found in one of two views: the Now view or the Later view. I don't think of time in specifics, so focusing on time in this general sense felt more natural to me. Any task with a Check-In Time on or before the current time can be found in the Now view, as well as any tasks without a Check-In Time. The Now View is subdivided into the Docked, Surfaced, Anchored, and Submerged groups, whereas tasks in the Later View are grouped by their Check-In Dates. You don't have to worry about these groups too much because Sort Stack automatically assigns tasks to their appropriate groups. Additionally, there are Now and Later buttons for each task to facilitate the movement of tasks to these views. The Script extensions for each of these buttons are in separate views to allow you to toggle between the two views that I expect most users will use most often without having to use Airtable's dashboard section menu since Airtable automatically switches to the dashboard containing the script extension that was triggered by a button click. While the Now button is pretty self explanatory, you might be wondering how Sort Stack decides what "later" means.

I experience time in roughly two waves each day: one in the morning and the other in the evening. Each of these times represents an opportunity for me to reset. For the sake of simplicity, I defined the start of the morning as 7 AM and the start of the evening as 7 PM. The Later button assigns the Check-In Time to whichever of these times is closest to the Check-In Time. Sticking with our seafaring theme, these morning and evening times are called Crest Times.

Maybe Later

Tasks with the Resigned status and the Meaningful Boost appear in this field. This field is not intended to be one to which you intentionally add tasks. Rather, tasks should serendipitously find their way into this view. This is done to discourage the formation of a "junk drawer" of bucket list tasks that you never get around to doing. Sort Stack is designed to encourage users to resolve tasks, not store them away indefinitely. It's partially because of this anti-storage philosophy that task areas (e.g., "Work" and "School") are absent from Sort Stack, as well as why Docked (Inbox) tasks are displayed in the Now view instead of in their own one.

Queries

Views for displaying a custom cross section of your tasks. This is also where you can take advantage of the secret Task Chain Number property. If you group the tasks in this view by project and only display unresolved tasks, you can sort by this number to see the order in which tasks should be resolved. This is also the number that's used in the Plank view to suggest how many days in the future Submerged tasks should be scheduled.

Task Dependency

Tasks can be assigned predecessors. Tasks that are linked together form what's called a task chain. One of this feature's primary uses is to break tasks down into steps with a small enough scope that they could be resolved in one session. If you find yourself faced with a task that has either the Survey or Progress intentions, you should consider preceding such a task with a smaller one that does have the Resolve intention. If the predecessor task doesn't call for the Resolve intention either, it's recommended that you continue to break down the task until you've arrived at one that you are confident you could resolve in one session. As a bonus, tasks can belong to multiple task chains.

Projects

Automatic Project Management

The threshold past which a task becomes a project for me is much lower than the average person's. This means that tasks like cleaning the kitchen can easily become projects to me. It was this experience that inspired the automatic project creation feature. This feature automatically creates a project when a task is linked to another one via the Predecessors field. For instance, if the task "Eat Dinner" was linked to the task "Order food from DoorDash" via the Predecessors field and neither task belonged to a project, a new project called "Eat Dinner" would be created containing the tasks "Eat Dinner" and "Order food from DoorDash." In addition to automatic project creation, all of a project's properties are automatically generated using the data contained within the tasks linked to it. Consequently, you could technically avoid ever going into the Projects table. Projects are even automatically "checked off" (resolved) when all of the tasks linked to them are resolved.

Multiple Projects Per Task

A task can be assigned to multiple projects because why not? I originally limited each task to one project, but due to some oversights in how I configured the base, some tasks accidentally wound up with multiple projects anyway. After realizing that this didn't really cause any major problems, I addressed the handful of issues that tasks belonging to multiple projects caused and made it an official feature.

Google Calendar Integration

This feature came about due to my frustration with the task scheduling feature I kept seeing in more advanced to-do list apps. Tasks aren't events and therefore shouldn't be treated like them. For one, I often struggle to stick to the schedules that I make, so trying to schedule all of my tasks often results in an excessive amount of time spent updating my schedule. Secondly, many tasks are worked on multiple times. There have been many homework assignments I've had, for instance, that require multiple sessions to complete. Thirdly, I heavily rely on my to-do list, so it's not uncommon for me to have over 100 tasks on my to-do list on a given day. Trying to schedule all of these tasks, only to probably have to reschedule most of them, would be far from an efficient use of my time. However, there's no denying that tasks and events have a natural symbiosis, which is why this Google Calendar integration allows you to link calendar events to tasks via the following two fields in the Tasks table:

1. Anchor Event: Overwrites a linked task's Check-In and Checkout Time with its Start and End Time. This kind of event is useful for time blocking. Additionally, you can link Anchor Events to milestone tasks in a task chain, since doing so will display these tasks in the Anchored group instead of the Submerged one.
2. Buoy Event: Overwrites a linked task's Deadline with its Start Time. This is useful for tasks that need to be resolved before an event starts, such as preparing for a presentation. Because the values are synced, rescheduling this event would automatically update the linked task's Deadline to match the event's new Start Time.
3. Floaty Event: Overwrites a linked task's Checkout Time with its Start Time. This is useful for tasks that you would like to be resolve before an event starts. Because the values are synced, rescheduling this event would automatically update the linked task's Checkout Time to match the event's new Start Time. However, note that Anchor Events are given priority over Floaty Events, meaning that this effect will only be observed if a task is not linked to an Anchor Event.

Notifications

Sort Stack is capable of four different kinds of email notifications: Reminder, Imminent Deadline, Almost Due, and Overdue notifications.

Reminder notifications will fire at the time set in the Reminder Time field of a task. Since assigning this task a time on or before now will almost immediately trigger a notification, it's recommended that you set the Reminder Time's date to at least one day in the future, set the time you want, and then revert the Reminder Time's date to today for tasks that you'd like to be reminded of during the same day you set them.

Imminent Deadline notifications are automatically fired for tasks whose Deadlines are less than 12 hours away.

Almost Due notifications are automatically fired for tasks whose Deadlines are less than {Task Resolve Threshold} minutes away.

Overdue notifications are automatically fired for tasks that are overdue.

All notifications are batched to prevent spam. This means that if you're supposed to be notified by a type of notification for multiple tasks simultaneously, you'll only receive one notification. Additionally, all notifications include tasks of which you were previously notified that you haven't yet resolved, meaning that you can comfortably delete all but the most recent instance of a notification type from your email inbox.

Extensions

Events on the Horizon

While this view is primarily for showing you upcoming events, it has one key feature called "Speed Mode" that I'd like to bring to your attention. This feature suggests what speed you should be roughly be moving at to resolve all of the tasks with the "Resolve" intention linked to a given event. The five speed modes are as follows:

1. Clarify: For situations where none of the tasks linked to a calendar event have the "Resolve" intention. This mode should be interpreted as a suggestion to break down tasks into ones that have the "Resolve" intention.
2. Coast: Means that you can move at a casual pace.
3. Cruise: The "sweet spot" speed that you should strive for, as the other speeds are unsustainable.
4. Careen: The event is practically at capacity. You'll need to move quickly to resolve all "Resolve" tasks before the calendar event ends. You might want to consider taking shortcuts to finish tasks sooner, removing some tasks from the event in question, or increasing the duration of the event.
5. Capsize: The event is overloaded and you are highly unlikely to resolve all of the tasks linked to the event in question. You should either increase the duration of the event or remove some tasks from the event in question.

To Schedule Passage Plan

This extension presents a list of tasks that Sort Stack suggests you link to an Anchor Event. Consider linking predecessors to tasks in this view before scheduling them, as building task chains should be prioritized over scheduling tasks. Assigning a task displayed in this extension the Waiting status or a boost are also ways to remove these tasks from this extension and are actions you should consider taking before scheduling tasks.

As of August 23, 2024, this feature was rolled into the new Passage Plan feature, which gives you hints regarding how you should consider approaching your tasks. This feature introduces three workflows that likely require explanations: Waypoint Identification, Drafting, and Handoff.

Before: Waypoint Identification

A Survey intention workflow for finding "epiphany vectors", which are significant realizations about the problem you're trying to solve that point towards to a solution. I've found the most consistent way to do this to be creating an outline representation of the problem space — kind of like a DOM (Document Object Model) — to gain a better understanding of said space while identifying gaps in your understanding of that space. Some of those gaps could wind up being gaps in the problem space itself, which could lead to tasks to add to Sort Stack. Later, a DOM-like document can be created that outlines what your solution to the problem will be. This document would serve as something like a homework assignment to yourself, meaning it should contain specific information regarding what form the solution is expected to take (e.g., an essay written in Microsoft Word + a flow chart created in FigJam).

While on the topic of waypoints, I'd like to take a moment to highlight the recently added (as of 2026-01-02) "Ballast" field, which can be found in the Projects table. This field is intended to surface a project's meaningful deliverables that you Resigned, as I have found that I often have trouble determining how best to progress towards the resolution of a project because I can imagine too many ways to do so. However, despite often envisioning several paths that I could take to make progress on my projects, they usually mostly all arrive at roughly the same "destination". That "destination" is often too far away to try arriving at in one go. Regardless, this is often the direction I find myself going in due to ADHD all-or-nothing thinking. By giving up on these "destination"/final waypoint tasks, I can replace them with smaller-scoped waypoint tasks. Put another way., by initially biting off more than I can chew, I'm able to determine how much I'm actually capable of chewing and can use that knowledge to plan more manageable bites moving forward. Projects that you're stuck on that lack Ballast might be ones with waypoint tasks that you might not have even formally added to them. In such cases, it might behoove you to set aside some time to identify the expected outcomes of a project you're stuck on to determine whether said outcomes are too ambitious.

During: Drafting

Progressing towards the resolution of a Progress intention task by "drafting off of" a Resolve intention task. I've found that focusing primarily on a task that I know I can resolve at any time makes it easier to make progress on tasks that I'm not sure I'll be able to resolve in one session. The task drafted off of helps me not feel "trapped" by the Progress intention task since I know I can resolve the task drafted off of at any time, which would also signal the end of the session spent making progress on the Progress intention task. It's kind of like how you would likely feel more comfortable meeting a stranger in a place with an easily accessible open door, such as a café, as opposed to a windowless room whose only door is one blocked by said stranger.

After: Handoff

The purpose of this directive is to encourage the user to make some kind of progress on a task that they may have been unable to make significant progress on during the linked Anchor Event by "handing it off" to either someone else or a future version of themselves. The former kind of handoff could be accomplished by doing something like adding a predecessor task for asking a co-worker a question that would help you better understand a problem space associated with a task you were assigned, while the latter kind of handoff could be accomplished by doing something like adding a predecessor task for developing some aspect of their problem space "DOM" further. For both types of handoff, Sort Stack wants you to add a predecessor task to the handoff one and eventually get to the point where that predecessor task is assigned the "Waiting" status. The justification for this expectation for internal handoffs (handoffs to future you) is that you're waiting on your subconscious to better understand a task's problem space due to the Zeigarnik Effect.

On Deck

This extension is intended to be a slight source of encouragement. I'm used to feeling behind schedule a lot, which is one of the reasons why I was compelled to search for the ideal task management system for me. After over five years of searching for such a solution and failing to find one, I started developing Sort Stack. After a while of using Sort Stack, I noticed that I started running out of Tasks in the Now view to work on, which drove me to checking the Later view for Tasks to work on. The Ahead of Schedule extension presents a cross section of the tasks in the Later view that are genuinely ahead of schedule, since many tasks in the Later view are there because they're meant to be done later. You can check out the filter rules of the view in the "Back-End" views section of the Tasks table if you're curious about the conditions that must be met for a task to appear in this view. However, if you want my advice, I wouldn't worry about it too much and just be happy if tasks appear in this extension. If you don't intend to work on a task until its scheduled time, you can assign it the Waiting status and it will disappear from this extension.

Task Map

Addresses in the Location fields of linked calendar events — whether they're Anchor or Buoy Events — will be displayed on a map if any of their calendar events are linked to tasks in the Now View. Note that this feature will only work if the address in the location field is formatted properly. The advantage of pulling a location from a linked Google Calendar event is that Google Calendar automatically formats addresses, meaning you shouldn't have to worry about that caveat.

Weather

Weather forecasts that change automatically depending on your location courtesy of Meteoblue.

Tides

Tides is Sort Stack's version of a habit tracker that is based on the concept of batching hours for work. When a tide is checked off, its next instance is displayed in the "Ahead of Schedule" extension. This gives you the option of resolving the next tide earlier than planned. The more frequently you resolve tasks ahead of schedule, the more time you've bought yourself until the next time you're supposed to do the tide. For example, let's say you had a tide for practicing the piano and had to go on a vacation for a few days. With a typical streak-based habit tracker, you would feel bad about having to break your streak because you would not be able to practice piano while on vacation. However, with Sort Stack's approach to habit tracking, you could just complete the practice sessions you were going to miss in advance, just like how some companies let you work additional hours earlier in the week, so you can leave work early on Friday.

This kind of habit tracking has an ebb and flow, which is why "tides" felt like a more appropriate name for this feature than "habit tracker." It doesn't hurt that this term reinforces the nautical theme of this base as well. This ebb-and-flow approach to habit tracking is more forgiving and flexible than a traditional habit tracker, which I've found more compatible with how I work.

Time Tracking

I'm not a big fan of timers because they make me feel trapped. Even if I set the timer to a short time, I'm discouraged by the knowledge that I'm going to be stuck working on something for a predetermined period of time. To add, I sometimes feel like I work less efficiently with a timer than without because I feel like the task I'm working on should take as long as the timer is set for, even if I could finish said task in less time. For these reasons, I prefer to work with stopwatches.

You can use Airtable's Time Tracker extension — which is basically a stopwatch — to track how long it takes you to work on a task for one session. It's for this reason why the Time Tracker extension can only track the time of a task whose Time Tracked field is empty. It's important that the value in the Time Tracked field represents how long you worked on a task for one session because of the Resolve Threshold feature that is built on top of the time tracking one.

I also like to use the pomodoro timer app Session to help me remain aware of the passage of time during a focus session by setting it to the initial Event Resolve Threshold for whichever event's Anchor Event Tasks I've chosen to focus on for the time-being.

Resolve Thresholds

This feature is designed to provide light guidance for how much time you should allocate to a task and is composed of three variables: Task Resolve Threshold, Project Resolve Threshold, and Event Resolve Threshold. The Task Resolve Threshold is the average duration of one session devoted to working on a task. The Project Resolve Threshold multiplies the number non-Quick, unresolved tasks with the Resolve Intention by the Task Threshold to provide a rough estimate of the maximum amount of additional time you should anticipate spending on a project. The Event Resolve Threshold follows the same principle as the Project Resolve Threshold, except for an event as opposed to a project. Please note that unfortunately, because Airtable doesn't support global variables, you'l have to manually update the Task Resolve Threshold formula field in both the Projects and Calendars tables. By default, the Task Resolve Threshold value is set to 27 minutes, which is the average Task Resolve Threshold for me. The nice thing about this threshold is that since all Quick tasks with the Resolve intention have a threshold of three minutes, linking one non-Quick and one Quick Resolve task to an Anchor Event or project results in a aggregate threshold of 30 minutes, a nice, clean number. If you want the Task Resolve Threshold to be a fair representation of how long a session of work lasts for you on average, it's recommended that you track your time for tasks of a variety of sizes.

Attachments

You can link attachments to tasks. Additionally, remember that because of how projects get their properties from the tasks linked to them, the attachments you link to a task will show up in the Attachments field of any linked project.

Distinguishers

A tag to help distinguish tasks from each other. For example, a student could use this property to indicate the class to which a homework assignment task belongs.

Reference Tasks

You can link any tasks to a task that are relevant to it. For instance, if you were a student working on extra credit assignment based on a previous homework assignment, you could link the previous homework assignment in question to the extra credit task.

Siren Types

The name of this field was inspired by the sirens from Greek mythology, which further reinforces Sort Stack's nautical theme.

In short, this field is for marking a task as a representation of an object.

This field is for records that aren't technically tasks, but rather task triggers that are capable of experiencing a "resolved" status. For example, the "Outline" type could be assigned to a record representing an outline. An outline is not a task, but it is something that can be resolved. Additionally, it could inspire a predecessor task like "Locate resource to take notes on." For this reason, the name of a task with a siren type should not start with an action, unlike a regular task typically would.

The "siren-ness" of this siren types is that they could lead you astray by causing you to drift off course. This is due to their ambiguity, as well as how they can inspire several kinds of actions, making them harder to resolve than regular tasks. For example, a task with the "Job Candidate" siren type could spawn several predecessors like "Coordinate with candidate to schedule a meeting with them" or "Ask candidate to provide the password to their portfolio website.

This field isn't intended to be used all the time, but rather for situations where many of the same task are subjected to the same workflow. In these scenarios, you could assign all tasks subjected to said workflow with the same type and then filter by that type in the Kanban Query view. Additionally, you can create a view that only has tasks of a certain type and then sync that view to another table. For instance, all tasks assigned the "Decision" type are synced to my "Delight" base, where decision-specific actions can be taken on them.

Lastly, this feature allows Sort Stack to be extendable, meaning that tasks can be sent to other bases to perform specialized functions. The types that are officially supported are Outlines and Decisions. Each of these corresponds to other Airtable bases I've created that I might release at a later date. You can add your own siren type extensions by creating a view that only shows tasks assigned the siren types you've created.

Recurring Tasks

Recurring tasks can be configured in the Task Templates table. Recurring Tasks can have one of two recurrence dependencies: Check-In Time and Resolution Time.

Check-In Time Recurrence Dependency

Check-In Time recurring tasks recur on predetermined days. For instance, a task set to recur every other day whose first instance was scheduled for a Monday would be next scheduled for Wednesday, Friday, Sunday, and so on. When a Check-In Time recurrence dependency task is resolved, its next instance will be assigned the closest predetermined Check-In Time. Returning to our earlier example, if you were to check off the task on Monday or Tuesday, the next instance would appear on Wednesday. However, if you were to check off such a task on Wednesday, its next instance wouldn't appear until Friday. Despite the times of Check-In Time recurrence dependency tasks being predetermined, the next instance is not created until the current instance is resolved. This is in adherence to one of Sort Stack's design goals, which is that Sort Stack shouldn't move unless the user does. This design goal is intended to decrease the pressure a user might feel to maintain their to-do list, which should in turn make Sort Stack a less stressful app to maintain.

Resolution Time Recurrence Dependency

Resolution Time recurrence dependency tasks' next instances appear the same amount of time after the current instance is resolved. If you configured a recurring task of this type to recur every two days, each instance of such a task would be scheduled for two days after the resolution time of the current instance.

As an added bonus, recurring tasks can be checked off ahead of schedule, meaning from the Later view. Speaking of bonuses, recurring tasks can recur down to the minute, which is great for tasks like taking certain medications that need to be taken multiple times per day.

The Task Templates table is modeled after the Tasks table since the values in the fields are copied into the fields of a new task. When you're done filling out the fields, click the "Active" checkbox to activate the recurring task. A new instance will automatically be created for you if one doesn't already exist. In addition to these two kinds of recurring tasks, there are modifiers that can be applied to refine recurring task instances.

Eligible Weekdays Modifier

One modifier is called "Eligible Weekdays," which can be used to indicate which weekdays to which a task's Check-In Time is allowed to be set. A recurring task that lands on an ineligible weekday will have 24 hours repeatedly added to its Check-In Time until it lands on an eligible weekday. It's highly recommended that you populate this field while a recurring task template is deactivated, since this modifier is automatically activated as soon as a day is selected, meaning it could activate before you were finished selecting the days on which you wanted a task to appear.

UPDATE: As of August 23, 2024, you can specify the Eligible Weekday search direction. This means that if a task lands on a day that's not within the set of eligible weekdays provided, you can tell Sort Stack whether to search forwards or backwards for an eligible weekday. I added this feature because a place where I recently worked paid me on the 15th and 30th of each month, but if a pay day landed on a weekend day, we would get paid on the weekday that most recently passed. For instance, if I got paid on the 30th, but the 30th was a Sunday, I would get paid on the 28th instead. It's worth noting that if want to use this admittedly niche feature in the way described in the provided example, you should also check the option "Don't Copy Snapped Times to Task Template", so that all recurring task instances will start on the default day of the month.

Note: If no eligible weekdays are provided, all weekdays are considered eligible.

Round-Based Recurrence Modifier

The other modifier is a round-based time, such as the 2nd Sunday in May (for Mother's Day). For this kind of modifier, the Check-In Time just needs to be a date within the month you would like the next instance to appear. For example, I could pick May 1, 2024 at 7 AM if I next wanted to see this Mother's Day recurring task at 7 AM on Mother's Day 2024. Note that while the date just needs to be in the month of the year you want, the time should reflect the time of day you would like the task to appear. From there, if you want to use any of the other date fields (Checkout Time, Deadline, and Overdue Deadline), the difference between any of these fields and the Check-In Time you selected will determine the times to which these properties are set relative to the round-based time. For example, if I wanted to give our example task an Overdue Deadline that was one day after the round-based time (the 2nd Sunday in May), I would need to set it to 1 day after the Check-In Time I picked (May 2, 2024, if we're sticking to the same example). You can also choose how much earlier you want the Check-In Time of this task to be relative to the round-based one. Using our Mother's Day example again, you could specify that you want the recurring task to appear three days before Mother's Day.

Day-of-the-Month Recurrence Modifier

This modifier is for situations where you want a task to appear on a day based on the end of a month, such as the second to last day of every month. This is accomplished using negative numbers. You input a Check-In Time that is anytime within the month after the month you want the task to start and then use negative numbers to indicate which day of the previous month you'd like the task to appear on. -1 refers to the last day of the previous month, -2 refers to the second to last day of the previous month, and so on. The other times are relative to the Check-In Time you provide, meaning that if you wanted a Deadline that was schedule for 12 hours after a scheduled Check-In Time, you should set the Deadline to be 12 hours after whatever Check-In Time you provide.

Crest Time Modifiers

The last modifiers snap a recurring task's Check-In Time to its nearest Crest Time and its Checkout Time to its next nearest Crest Time.

Modifier Prioritization Order

If multiple modifiers are simultaneously active, only the top priority modifier is applied. The priority order of the modifiers is as follows: 1) Round-based recurrence, 2) Eligible Weekdays, 3) Snap Check-In Time to Nearest Crest Time and Snap Checkout Time to Next Nearest Crest Time. 2026-01-02 Update: I recently reworked the Task Template table's view structure within the Upper Deck section by breaking down the one big table where most of the task template configuration was expected to take place into several views that each feature a set of related fields that can be used to configure task templates. These views are intended to be visited from top to bottom.

Name-Incrementation

The binary exponential name-incrementing function is great for building a bit of momentum to help you get through repetitive tasks, like folding laundry or powering through emails or browser tabs (surely you don't have too many of those open, right...?). For instance, if "Number of browser tabs to clear:" was your task template name, instances could look like "Number of browser tabs to clear: 1", "Number of browser tabs to clear: 2", "Number of browser tabs to clear: 4", etc.

The linear name-incrementing function allows a task to be appended by a number that gets incremented each time a new instance of a task template is created. I originally made this feature for tasks I found myself creating for binge-watching a show (I'm pretty sure it was Barry). It seemed inefficient to make several tasks that had similar names (e.g., "Watch episode 1 of Barry," "Watch episode 2 of Barry"). With this feature, I can now just configure a recurring task named "Barry:" and tell Stork to start by appending "1.01" and increment by "0.01" each time a new instance of that task template is created, resulting in tasks like "Barry: 1.01" (Season 1, Episode 1), "Barry: 1.02", etc. I can set the stopping condition for this recurring task equal to the number of episodes in the season, so that Stork doesn't generate task template instances for non-existent episodes of the show. To seamlessly transition into the next season, as well as do any other things I'd like to do after the season is over, I can link...

Task Template Successors

Task Templates can be assigned successors. If a task template is automatically deactivated, it will trigger the activation of all linked successors. However, if you'd like to delay the automatic activation of a succeeding task template, you could give the successor whose automatic activation you'd like delayed via the addition of a "Predecessors' Deactivation Count Limit". This tells Stork how many predecessors' automatic deactivations need to happen before the task template you assigned the limit to should be automatically activated. For all you super-nerds out there, something special happens when you assign a task template itself as a successor: Its times are updated while remaining deactivated after automatic deactivation. This is useful because task templates don't update their times until they're being used a succeeding time, meaning that a task template that gets automatically deactivated would never get the chance to update its times. This little feature works around that limitation.

I make use of this self-successor slight-of-hand for the two recurring tasks I use for taking out the trash: "Take out the trash" and "Bring the trash cans in from the curb." Each of these task templates has a Resolved Tasks Count of 1, making them perfect candidates for this little feature. Once I check off an instance of "Take out the trash", the "Bring the trash cans in from the curb" successor is automatically activated, which produces a successor the day after "Take out the trash" was scheduled for. Simultaneously, Stork prepares next week's "Take out the trash" times since I assigned that task template itself as a successor as well. The "Bring the trash cans in from the curb" task template has the same successors as the "Take out the trash one", creating a little task loop. With this configuration, if I were to not take out the trash one week, I wouldn't see a task for bringing the trash cans in from the curb.

Sort Stack Scheduling Method

Layers

If you're looking for guidance on how best to use calendar events to schedule your day, consider using this time blocking strategy. You'll need three calendars: May, Might, and Must.

1. May: For events that will happen regardless of whether you attend, but that you not be penalized for missing. An example of this kind of event could be a radio show or Twitch stream that you want to catch. I personally like using this calendar to indicate when stores are open (e.g., "Hours | Whole Foods" 9 AM–9 PM), as well as when Evening Golden Hour is (e.g., "Hours: Golden: Evening" 4–5 PM). Another example of how you could use this calendar is to indicate when a certain weather condition will be live (e.g., "Hours: Weather: Rain" 3–6 PM)
2. Might: For time blocking.
3. Must: For events that you have to go to, such as meetings and doctors' appointments.

On top of the calendar layer is a type layer. The following 10 types are available:

1. Meeting
2. Appointment
3. Occasion: A special event
4. Hours: Can represent the hours during which an establishment is open on a given day or during which the sun is in the sky.
5. Travel: Represents travel time
6. Shift: For transitioning into a time block that immediately proceeds the Shift one
7. Obligation
8. Flare: An event that's usually an all-day event that spans multiple days that's supposed to span the days leading up to the day of an event that you really want to ensure you don't miss. This event type was inspired by HEY Calendar's Countdown feature.

The third layer of this system is the naming scheme layer. The naming scheme for calendar events is as follows:

Type (required) | Distinguisher (optional):

Consider an event named something like "Meeting | CS 281: Lecture | 1.1" that was added to the "Must" calendar. This event represents the first lecture of the first week of the academic term that a student has to attend for their CS 281 class because the professor takes attendance. If the professor didn't take attendance for lectures, this hypothetical student could add this event to the "May" calendar instead of the "Must" one.

This system is designed to be calendar-app agnostic, but some calendar apps have official tag support, which you could use to store the aforementioned types. However, the type should still be mentioned in a calendar event's name, so that every event's tag assignment will be saved, even if the calendar app in question ceases to exist.

Constellations

Sextant

A sort of task loot box containing tasks Stork thinks you should assign to one of two special time blocks: "Hours: Constellation: Longitude | {number of day within current "sprint", as defined by an event called a Latitude event}" and "Hours: Constellation: Latitude | {date that Latitude event ends".

Longitude Events can be thought of as deep work blocks. Two should be scheduled each day: one during the daytime and one during the evening or nighttime. This is based on my observation that I tend to have two times per day that I feel like my focus peaks: once around 3 PM and once around 3 AM. From roughly those times, my focus tends to taper off until the roughly the next Crest Time. Putting all of that information together, I tend to schedule my Longitude blocks from 3 PM to 7 PM and 3 AM to 7 AM. Guess which block I roughly started writing this passage in 😅. Tasks that Stork suggests you link to an active Longitude event are ones it thinks matter enough to you that you should set aside time to work on them. For example, many of the tasks that Stork suggests I assign to an active Longitude event are ones related to working on Stork since that's something that matters a lot to me.

Latitude Events can be thought of a bit like sprints for those who are familiar with Agile methodologies. I came up with the idea for this kind of event because I kept finding myself frustrated that there were only 24 hours in a day. Creating a multi-day event that spans from the current day through the current Scheduling Horizon 's date was the closest I was able to come to addressing that problem. Tasks that Stork suggests you link to an active Latitude event are ones it still thinks matters to you, but that you should mull over over the course of the current "sprint" since only tasks you're stuck on — as indicated by the Survey intention — can be assigned this suggestion.

Coordinate Events (get it, like what you get when a longitude and latitude line intersect?) — unlike Longitude and Latitude ones — are ones that can be linked to tasks however you see fit. Nevertheless, for most people, this will serve as a way to partake in conventional task-based time blocking. I don't think that dragging tasks onto a calendar makes sense because calendars aren't optimized to handle large quantities of tasks, unlike to-do lists. Coordinate Events, on the other hand, don't progressively clutter up the calendar more as the quantities of tasks linked to them increase.

All three of these events — Longitude, Latitude, and Coordinate ones — belong to the "Constellation" group of events, hence the "Constellation" part of the names of instances of these events.

Plank

A place where Stork helps you decide when to schedule submerged tasks and anchored tasks whose Anchor Events have finished. You don't have to worry about scheduling a task too far in advance regardless of whether it appeared in this view because if you either assigned said task the "Queue" status or linked it to a calendar event via the Anchor Event field, it will appear in the "On Deck" view.

Planisphere

A place to observe the "constellation" you created with the tasks you linked to Constellation events.

The Gaze group is for tasks you might want to monitor, while the Bask group is for helping you savor your wins, meaning the tasks linked to Constellation events that you resolved.

Caveats

• Try to avoid adding commas to task names, as this can result in the creation of unwanted projects because of how Airtable parses records.
• Avoid creating "task loops," such as when a task is assigned itself as a predecessor. Doing so will cause your whole task chain to get stuck in the Submerged group.
• To ensure each task's notes don't run together in their corresponding project notes, you need to start each note with two blank lines. Next, you should write a descriptive heading for your note on the third line and then start writing the contents of your note on the fourth line. I know this is a pain, but Airtable doesn't let me customize the separator used in the Rollup field that displays a project's notes. Speaking of notes, there's a hidden "Exclude Notes from Projects" checkbox in the Tasks table you can click to — as the name suggests — exclude a task's notes from all projects to which it's linked.
  • UPDATE: As of October 16, 2023, you no longer have to prepend each note with two blank lines. I realized that I could use a formula field to automatically prepend the two new lines to each task note, so that the project notes have the appropriate spacing. However, it's still recommended that you write a descriptive heading at the top of each task note.
• Airtable limits how many automations can be run each month. As Sort Stack is a very automation-heavy base, you could wind up accidentally exceeding your monthly automation runs allowance. You can mitigate the number of automations run by linking Anchor Events to milestone tasks. Doing so prevents anchored tasks, as well as their successors, from getting yanked by the "Yank Task Chain" automation.
• Airtable's Automations can often take several seconds (typically up to 10 seconds) to activate. The main scenario where this may pose a problem is when you're linking predecessors to tasks, since proceeding to lengthen your task chains before the project management automations are triggered could cause some tasks to not end up linked to the projects to which they were supposed to link.
• Airtable can sometimes be slow to send Sort Stack's notifications, so it's not recommended that you heavily rely on Sort Stack's notifications for tasks that you must be reminded of at precisely the time anticipated or requested.
• If a lot of tasks trigger a notification at the same time, it's possible to get two notifications instead of the intended one. This appears to be a timing issue caused by not all tasks triggering the notification automation simultaneously. For now, at least, there's no fix for this behavior, but it's not one that throws any errors or otherwise breaks any part of the system. As of June 22, 2024, this (should) no longer be an issue! This feature was originally a lucky mistake that I didn't fully understand. The updated implementation of this feature properly codifies the desired behavior of the mistake while addressing that mistake's artifacts.
• When configuring recurring tasks that are only to recur on eligible weekdays, you need to assign an initial Check-In Time that's on one of those days. Otherwise, Sort Stack will not prevent tasks from settling on non-eligible weekdays until after its settled their first eligible one.
  • UPDATE: As of October 8, 2023, this caveat no longer applies!
• Sometimes, the Google Maps extension can incorrectly place pins on locations if you provide a URL as an event location; the extension interprets some combinations of URL characters as abbreviations of places, which is why pins can sometimes be placed incorrectly. For instance, if you provide a Google Meet URL with the combination of characters "zwe," the Google Maps extension might think your event takes place somewhere in Zimbabwe.
• This should go without saying, but the Time Count of a Task Template must be greater than zero for corresponding recurring tasks to be scheduled for the future.
• Some of the cover images are a bit out of date, but I chose to leave them to highlight a bit of the evolutionary process that Sort Stack underwent.
• As of July 4, 2024, notifications have regularly been firing over 10 minutes late. This seems to be due to Airtable's NOW() function fetching the new current time less frequently than is ideal.

Logistics

• Please note that a Team an Airtable Pro, Creator, or Enterprise subscription is required to get the most out of Sort Stack. This is namely to significantly decrease the chances of surpassing your monthly automation limit; Sort Stack is a very automation-dependent Airtable base, so the ability to comfortably have thousands of automations run per month is practically essential to fully experiencing Sort Stack. Additionally, Sort Stack's extensions — while not as essential as its automations — are a key aspect of the experience; Sort Stack's Tasks table's Now view — combined with the extensions in the Dashboard section — collectively present you with practically all essential information, so that you don't have to go on a scavenger hunt through the base in search of what you should care about from moment to moment.

Procedure for minimizing errors if mass-deleting tasks in Stork

1. 1. Turn off the Update Last Saved All Tasks Count automation
2. Turn off the Create Project From Task Chain automation
3. Delete all of the tasks you want to delete
   • If you'd like to create a Query view containing all of the records you'd like to delete, I'd recommend starting with recurring task instances.
     • Query to Use: Task Template Is Not Empty AND Is Resolved = 1 AND Resolution Time is on or before exact date {date of choice}
   • Consider downloading a CSV of the records you choose to delete

If any tasks linked to task templates were deleted:

4. Unlock the Last Saved All Tasks Count field in the Task Templates table

5. Clear all of the Last Saved All Tasks Count field cells of all Task Templates linked to tasks you deleted earlier.

• You could just clear this field for all Task Templates if you're not sure which ones' Tasks you specifically deleted.

6. Lock the Last Saved All Tasks Count field

7. Turn Update Last Saved All Tasks Count automation back on

8. Unlock (meaning set to "Editors and Up") the Confirming Sufficiently Completed Tasks Count Start Time Automatically Updated field in the Tasks Templates table

9. Clear all of the Confirming Sufficiently Completed Tasks Count Start Time Automatically Updated field cells

10.. Lock (meaning set to "Nobody") the Confirming Completed Tasks Count Start Time Automatically Updated field

11. Unlock the Next Check-In Time Updated by Last Time Resolved field in the Task Templates table

12. Clear all of the Next Check-In Time Updated by Last Time Resolved field cells

13. Lock the Next Check-In Time Updated by Last Time Resolved field

14. Delete any projects that appeared in the Docked group of the Now view of the Projects table as a result of the deletion of the tasks that you chose to delete.

15. Turn on the Update Last Saved All Tasks Count automation

16. Turn on the Create Project From Task Chain automation

Closing Notes

• You may need to empty out the trash as well for Airtable to say that you're no longer over the record limit. This can be done by clicking on the counterclockwise arrow and clicking on the Trash menu option.
• If you're under the limit, you should be able to create new tasks again, even if Airtable says otherwise. You just need to give Airtable time to realize you're no longer over the limit for the "Over limit" indicator to be removed.