A lot of us have asked about the ability to archive / retire assets for various reasons. Another reason I can add is that I use integrations with ITGlue and WarrantyMaster, and every asset I have in the Syncro system is synced with those systems. First to ITG, then to WarrantyMaster from ITG. Once an asset is retired, I don’t really need to see it in there, especially with WarrantyMaster because I have a certain amount of assets I can track warranties on with them, and don’t need to track assets I no longer manage. There needs to be some sort of way to segregate, and I am hoping that archiving them when that ability comes along is the way to go.
Does anyone else have issues with this and have found a way around it, other than just deleting the asset?
We have a Customer named “Retired Assets” we move assets to. We then apply a policy titled “Parking Lot” that does nothing (removes AV if applicable) and the only remaining action is to email if the asset comes back online for some reason. This might not work for you with the ITG integration… But it works here.
We have been using a custom Status field on Assets with a Date field attached.
Status: Active / Inactive / Retired with the date of the action.
It’s functional but you need to do extra work on Filters, Billing, and general Asset searches as they still show up in there.
We have also done an “Inactive” Policy which is also useful, but the items still tend to polute the list and show up on reports when we really only want them for historical purposes or in case they come back online.
We have started just deleting some since it’s not been as smooth as we’d like. Syncro should implement something similar to this but have the default searches not show “inactive/retired” assets OR customers OR contacts, etc. Same with any entity in there.
Topic closed on April 9th. Guess they decided its not important to them. It is also important to me. As a non-syncro device retaining the computer asset settings like CPU, motherboard, Memory, hard drive etc is helpful to be able to pull a decommissioned asset would help to show “spare parts” that could be used, or recommission the asset at some date as a spare.
From my testing, if an Asset is deleted, any Tickets which had that Asset listed in the Relevent Assets List, no longer have any information suggesting that those Tickets ever had a linkage to an asset.
Even in the change history of the Ticket, there is no mention that the now deleted Asset used to be relevent to the ticket and has been removed from the tickets Relevent Assets list.
I find it difficult to understand why Syncro is not seeing this as a priority to fix.
Or understand what the business logic is to leave things as they are.
IMO, improving Syncro so that MSPs can set Assets to a Archive, Not Active or similar status should be considered urgent.
In the SaaS world you never have as many development resources as you’d like, and you always have enough feature requests from your users to fill a 10-year roadmap. This means prioritization is the key, and that takes into account a great many things. One of those components is the sheer amount of support for any given request. This one has been requested in the past, but it is no where near the top of the list. That doesn’t mean it’s not important, or that we don’t want to do it. As I stated above it’s a request I support, and I agree on the value it would provide.
Syncro is improving every single day, and we’ve been hard at work delivering on some of our most requested features. Our Windows Patching overhaul is in the process of rolling out now, allowing granular approval settings (including Reject) for each category/severity, our new Defer mechanic, and the ability to block patches by KB. We rolled out our brand new Mac agent shortly before that, and late last year we completed our Policy Inheritance rollout.
I have no doubt we’ll eventually tackle this one as well, but as I mentioned above it’s not going to be in the immediate future.
As someone that also has a software development side of our business, and tried and failed to launch a unique product to assist MSPs, I completely understand where you are coming from in regards to resources and wish lists.
The current feature set in Syncro is about 10 years ahead of Naverisk, which on the IT MSP side of our business is the RMM we have been using for many years until now.
At the moment it feels like Syncro is investing and improving at a steady rate, this is excellent.
Though unfortunately Syncro is not accurately measuring the needs of customers. Only by providing a process that feature requests can be voted on, will Syncro be able to accurately assess the needs of the MSP community that Syncro serves.
Voting on feature requests only tells part of the story. When you are working with finite resources, it’s far more efficient to tackle like items at the same time in any given part of the platform. So if this request were much higher on the list, we’d likely flag it for development when we tackle other asset-related items as well. It doesn’t mean all things work this way, but it is part of the prioritization process.
One example would be where we have a ton of miscellaneous requests revolving around the PSA. We’re spinning up some larger PSA-related items , so these smaller requests are likely to get worked as part of this project.
Depends on how Syncro look at their customer base and what the spread of revenue looks like.
If the top 10 customers make up only 20% of the revenue, and there is a very long tail that make up the 80%, then meeting the common feature requests of the customers that make up 80% of revenue is very important. Even if individually each customer not in the top 10 have much smaller revenue than each customer in the 20%.
But if the top 10 make up 80% of the revenue, then it would make good business sense to keep that top 10 happy, even if doing so means that the rest are unsatisfied.
+1 on this - our business could also really use an archive asset/contact function. Old devices showing up in lists and reports is very messy and reduces our overall productivity but we don’t want to lose info by deleting them…
There isn’t much reason to keep stale requests in the forum indefinitely, particularly ones we know we aren’t going to be building. In the case of this feature, we are going to do this one someday. Not likely any day soon, but it is coming eventually. Others, not so much. Leaving them here “until they are shipped” implies every request is something we’ll eventually do. This is definitely not the case.
Discussions are open for 6 months on any topic, feature request or otherwise, so that should be plenty of time for folks to express their feedback on any given item.
If the request is not going to be implement, perhaps an official reply and a moderator initiated closing of the request. One of the benefits of hosting your own forum is that Syncro can be more directly engaged. Better to let folks know that they have to work around the limitations of the platform than to hope it will be addressed.
Comments in this thread show pretty clearly that wether intentionally or unintentionally it sends the message that Syncro isn’t interested in the feature requests that are closed. Of course it’s your call on what to do. I’m just letting you know that many folks already feel like they’re shouting into the void. Having feature requests auto-close with no official feedback does nothing but reinforce the feeling. And likely negatively effects engagement with the form.
It seems like stale topics in the Feature Requests & Suggestions category would less of an issue than the optics of auto-closing a popular request ¯\(ツ)/¯
Every request is going to have its day whether I or anyone else particularly likes it or not. We’ve implemented things in the past I didn’t personally like due to popular request, so closing things prematurely isn’t a particularly good idea. We’re also growing like crazy so we’re seeing sentiment shifts towards or away from any given requests as Syncro’s customer base changes and continues to grow.
There are no plans currently to change how our feature request system works, but any time anyone wants additional details on any particular item they should free to ping me. I have and always will be happy to engage with our users and discuss whatever they like, including their feature requests.
As far as this particular feature is concerned, I believe any questions about the priority and our desire to implement it should be answered at this point.