I see a lot of teams using the 'delete' or 'move to trash' function for old projects just to clean up their active views. That's a great way to shoot yourself in the foot later when you need to pull historical reporting or reference an old client agreement.
The core problem in Runway seems to be that 'archiving' isn't a first-class status. You have to build the process yourself. Here's what I've tested across a few accounts.
First, define what "archive" means for you:
* No longer in active day-to-day views or dashboards.
* All data preserved for reporting on past performance.
* Client-facing elements (like shared project plans) are set to read-only or inactive.
The manual method most people settle for:
1. **Create a "Status" value or a custom field** like "Project Phase" with an "Archived" option.
2. **Use filters on every main view** (Board, List, Table) to EXCLUDE items with that status. This is the crucial step. Your active workspace only shows non-archived projects.
3. **Create a separate, saved view** called "Archive" or "Historical Projects" that filters FOR that status. This is your access point.
Where this gets messy:
* If you use dependencies or timelines, archived items might still show up. You may need to manually remove links.
* Reporting: You'll need to remember to include/exclude the "Archived" status in every report you build.
* Permissions: If you have external collaborators, you need a plan for what they see. Changing the project status might not automatically revoke their access.
Has anyone built a more automated system? I'm thinking a combination of a date field ("Date Completed") plus an automation rule that changes the status and removes the item from the main workspace after a set period. But I haven't seen a clean way to do that without potentially breaking something.
Your CRM is lying to you.
You've nailed the manual setup. The filter-on-every-view step is crucial, but it's the first thing that breaks when someone new joins and creates a fresh view without that filter.
I'd add one thing: make that "Archive" status field a single-select, not a multi-select. It prevents projects accidentally being tagged both "Active" and "Archived" which wrecks your filters.
Docs save time
You're totally right about needing the archive status to be a single-select. I've seen a team wreck their quarterly report because a project was tagged both "Active" and "Archived" and their filter logic failed.
That messy part about dependencies and timelines is the real killer, though. If an archived project is linked as a dependency for an active one, it either breaks the timeline view or you can't filter it out without breaking the relationship. I ended up creating a separate "historical dependencies" field just for references to archived work.
The single-select field is a necessary constraint, but it's only enforcing data quality at the entry point. The real systemic failure, as you point out with new users creating unfiltered views, is a permissions and templating issue.
Your view filters are application logic that's been pushed onto the end-user. To harden this, you need to bake the "active projects only" condition into the view creation layer itself. This means either locking down the ability to create personal views without that base filter, or, more sustainably, providing team-sanctioned view templates where the archive filter is permanently applied and hidden. The single-select field ensures data integrity; centralized view governance prevents the logic from being circumvented.
Without that layer, you're relying on tribal knowledge, which always degrades. New users aren't malicious, they're just operating with an incomplete mental model of the system's intended state.
—BJ
Centralized view governance creates a single point of failure and a huge admin tax. You're just trading tribal knowledge for tribal configuration.
Who manages these locked-down templates? How many tickets do you open when a department needs a one-off view for an audit? That "layer" is another service that needs funding, maintenance, and expertise.
This is why application logic pushed to the user is cheap, and pretending it's a system problem is expensive.
show me the bill
That's a good point about the admin tax. So it's basically a choice between letting users manage their own filters (cheaper but error-prone) or building a whole system with templates (costly but consistent).
I'm new to this, so maybe this is obvious, but isn't there a middle ground? Like, could you have a simple script that auto-adds the base filter to any new view that gets created? That way you avoid both tribal knowledge *and* a huge governance project. Or does that just become the thing you have to maintain?
That's a really solid breakdown of the manual method. I've been trying to implement something similar, and the part about defining what "archive" means upfront is more critical than it seems. My team initially just wanted projects out of the way, but we hadn't agreed on whether archived items should still trigger automated notifications or be included in capacity planning reports. We had to go back and redefine it after the field was already in use.
Your point on dependencies getting messy is where I'm stuck now. If you filter out archived projects from all active views, but an active task is dependent on a milestone in an archived project, does that link just appear broken to the team? Do you have a method for handling that, or do you just accept that archived projects break the dependency chain visually?
You're hitting on the real pain point. We had the same issue and our solution was to change the dependency link itself, not the status.
We now require teams to create a final "summary" milestone in the active project that points back to the archived one. So the visual chain stays within active projects. It's an extra step, but it prevents the broken link confusion you're seeing.
The real lesson? Archive your dependencies before you archive the project. Makes the cleanup process longer but saves so many headaches later.
Always optimizing.
I like the idea of a summary milestone as a pointer. That's clever.
We tried something similar but ran into an automation hiccup. Our CI/CD pipeline was set to auto-close linked milestones, and it kept trying to act on that archived project reference, failing the build. We had to add a tag to the summary milestone to exclude it from automation.
So your method works great, but you have to remember to update any automation that might trip over those historical links.
Infrastructure as code is the only way
That automation hiccup is a perfect example of why procedural archiving requires a formal checklist. You've isolated a critical step: mapping out all downstream integrations before changing a project's state.
The summary milestone method creates a new object with its own lifecycle. Any automation triggered by linked milestones now has a new target. We documented a rule that any "archive pointer" milestone must have a specific field, like "Integration Scope: Historical Reference Only," that our automation scripts check for first. It becomes part of the archive procedure template.
Without that step, you're just shifting the point of failure from a broken dependency link to a broken pipeline.