I think a concept of archival rather than direct deletion is a good concept. Items shouldn’t be directly deleted and can only be archived. Archiving an item will gather all such items under an “Archived Items” list that can be either global to the instance (or later, under a “space” within the instance).
Archived items can be deleted permanently by user or can be deleted after x months as per admin preference. Archived items should be “restorable” in future (this will require much the same work as “undo” of delete otherwise planned now).
This archive concept is much like what’s there in Trello.
Seconded – came here to say that having an Archive option will be quite helpful. Right now a lot of new users are just beginning to fill out their new Fibery instances, but in the coming months we will start to have a whole lot of ‘complete’ tasks we’re filtering away
I noticed in Your recent display of top features in both the Oct. Update, and Here that you have “archiving of items” as a request with a decent amount of traction.
So I wanted to add in a vote for an aspect of this that has bounced around this post and the one below:
To review, this is the ability to set a time after which an Entity would “archive” itself out of visibility in a View. So for example, if I have a Board showing closed items, I can decide that I want to see items that have had their Workflow moved to a “closed” State within the last 2 weeks. After that time, I’d like them to auto-remove from the board.
This was one of the features my team relied on most in Jira, which has this. You can see in daily stand-ups for some amount of time what was recently done, so at a glance you get a good idea of recent progress. But over time the “done” items fade away, so you don’t get the board clogged with things that were done starting back from the existence of the Fibery Instance.
Interesting. I wonder if you could handle this with a Filter though, e.g. “Don’t show entities with “closed” view whose modify date is more than 2 weeks ago”. Granted it would get wonky if people frequently edited old/closed entities, but it’s something you could do right now, I think…
Hey, thanks. Is that a filter combo we can do now? Sorry I’m not an expert in these, but I can’t figure out how to put the filter on just that one particular workflow state of “Closed” so that all the other open items show on the board, too.
If you could show me this, that would be useful, and yes solve the issue. I could live with those odd entities that got edited some weeks after they fell off the board…
Hmm, actually I don’t think it may be possible with current filters because you can’t do more complex sub-filters, e.g. AND operation. As far as I know…
But I think adding that might be a better (i.e. more broadly useful) extension to the filtering features, than the particular request of archiving items after a certain period, which is highly specific (although I understand this feature does exist in other systems like Jira).
If we got a little more capabilities with Filters, such as some kind of formula so you could say “if Done, then show only those that have been modified within the last two weeks or sooner” then you would have what I’m looking for. From my point of view, that would fully handle the archiving need I have. Also, I would imagine more powerful filters have all kinds of other benefit, I’d be surprised if the team isn’t already planning some improvements at some point soon here.
I have thought that a workaround would be to add a Formula Field into each Entity in question, then filter on that. So like “if the state is ‘done’ and ‘modification date is over 2 weeks old’ then mark this field.” (sorry I don’t do formulas I hope that makes sense!). But again, this is an additional Field that I’d like to avoid if I can! I know that in Notion there are all kinds of things users try to do with Formulas like this, and wind up with tens of fields in their Pages which makes for a terrible UI experience, I think. Fibery has really handled this well so far with the Splitting of the view and other goodies. But like Coda, Airtable, Notion, we still suffer here from “Field Proliferation”. Dare I mention Polymorphic again!
And just to follow on this point, I do not want to hide “not done” items that are stale. Those are in fact very important to see in the board so we can catch stuff that is “getting stale” and should be attended to.
Yes, I do think it could be quite useful. Although the basics we have so far are already quite useful and cover many cases.
Yes, that would indeed work! And since I think we know that they are implementing hidden fields, if more sophisticated filtering does not come, or comes later, then once hidden fields are available you could use this method without cluttering things up.
Yes, very important here as well! I hate to admit it, but some tasks do just sit there for ages (sometimes by design, other times… )
Ok thanks, I did try it and it would appear to work.
So what you’re saying this is doing is:
The first filter shows anything in a state that is not “done.” No matter when modified
The second filter shows anything that has been modified within the last month? Including Done
So the part 1. will kind of supersede the entities that are older than one month if they are not “done,” because that is asking for anything that is not done? And I guess these two filters co-exist due to the OR nature.
Anyway this seems to work for now, unless I’m missing something still. So thanks!
Hi, and sorry again if this should be a Feature Request.
One of the things I’m hoping for in Fibery with all its flexibility is the ability to give the user the chance to come up with a custom archiving strategy.
I’ve met with quite a few ways this is handled in other apps:
Manual archiving: Wrike for example does not archive anything automatically. You have to create an “archive” area, and tag every archive task with this folder. “Done” tasks are removed from a lot of default views as they are not considered “active,” but this is a very limited solution, requiring way too much manual work.
Auto-archiving after a certain amount of time. Jira will remove issues out of a “done” column after a certain amount of time, into the archive. This is not a bad solution, as they are still visible in search results. But customizing this is a bear in Jira. I tested another app, Favro, that simply let you pick how many days a “done” item stayed in that column in one simple drop down.
Generally I would like to be able to archive certain entities, like the ones I use for tasks/issues such as in the apps I talked about above, but other entities I do not want to have archive at all, such as features of my website. I am not clearly seeing any evidence of archiving at all right now in Fibery. If this is intended, could you let me know if with the release of Automations there will be some good ability to, in essence, create a custom archive solution such as what I’m talking about here? Summing up, certain rules for certain entities so they’d effectively “disappear” from view into an archive, while other entities would not archive at all?
@B_Sp Obviously, we should implement archiving feature quite soon, since with time it becomes painful to live without it. We did not have nailed how it will work though.
As a temporary workaround, you may hide old items from done state using this filter:
@mdubakov, thanks for the tip, and I am impressed with the sophistication you already have built into the current filters!
This also occurred to me as a makeshift solution for the question I posed earlier here:
Where you would set up a view with a filter for just the last column that is the “done” state of a candidate that is potentially going to be hired, or a client prospect that you have now won. It occurred to me however this still wouldn’t solve that problem, as if I wanted to add relations across entities, and I have in the same type both CRM prospects, and CRM actual clients, I will always get a list of both. I suppose it’s not in the works to have variants of type lists available in other types that would be filtered?
Either way, as I think this through more thoroughly, I still think it would be a terrific feature to be able to convert/promote an entity from one type to another, and key being to bring all the data across, and note in the new entity a reference that it originated via a different type initially.
)