3 years too late on addressing this. We have stopped using KACE, and moved to ManageEngine.

I am still hopeful this will happen. This has been one of many items I would like to see soon.

Thank you for continuing to provide your feedback to the KACE team.

We are happy to be a stand-alone software company again - you should start to see some changes.

We prioritize all feature requests based upon many factors to maximize the customer benefit. We have been trying to address the top-voted items - please continue to vote on the items most important to you.

We've been in discussions for dumping our K1 and K2 as well. Beyond feeling like the product has been stagnant, I agree support has become inconsistent and unreliable. We renew our product support yet 3 months later, our license has "expired" mysteriously - again. ManageEngine does look interesting....

6 years later...

It is quite sad that It only took a few days over 6 years to include this request.

"This request should be implemented in a release this calendar year"...... too late, we are giving up on KACE later this year and moving to ManageEngine. Dell and Quest have been way too slow to implement needed changes, and the support has become atrocious.

Also note we are using LDAP labels to identify ticket owns and active users so that reduces the clutter in lists already

I agree with Graham Butter below that the simple solution is all that is needed. No change to the data structure, no removing users from past tickets, just simply an attribute that prevents disabled users from appearing in most lists of users by default

Hi! This is a database relational issue because how could it be posible that tickets exist without a specific user as solicitant, if the user can be deleted.
Delete a user must be imposible to do if this user has tickets (open or closed). This way no orphan tickets will exist.
The most simple solution is to add a flag field for the users "Active/Inactive". With that field, the application most filter only the ones with Active Flag.

I definitely vote for this. There are technicians in our owner list that have left over 2 years ago. I like this suggestion from Drew : "This really needs to happen. Maybe add an option to move a user or ticket owner out of the users list into a "retired users" list (which removes all labels). Then they can stay as the submitter or owner but not show in the normal users list or the ticket owners list."

This really needs to happen. Maybe add an option to move a user or ticket owner out of the users list into a "retired users" list (which removes all labels). Then they can stay as the submitter or owner but not show in the normal users list or the ticket owners list.

This is a must - can you provide any update on when this feature will be available?

I am a new admin on our system and looking into retiring two technicians from a queue. I am to understand there is no maintenance option to demote a user from being a technician to standard user, or to remove the user from any lists after they leave a company without removing them from the database records per each ticket? This breaks the 3NF basic database design tenant.

Count mine as a vote for this feature.

It's probably been said already, including in other usggestions, but I'd like to see this option include retiring technicians.

Why is this still being discussed and not implemented? I need to be able to remove users (queue owners and regular users) without having all the issues removing a user creates! So frustrating to see this has been a request for years with no movement.

I think we should have the ability to purge accounts that are beyond a certain age. Working in a school that has a relatively high turnover I have several stale accounts that are years old that I sometimes try to delete by hand

I'm doing the research for academic purposes. Regarding the use of software Kace

This investigation is based on the ISO / IEC 25010/2011, which evaluates the quality of product software.
I count on the participation of all to get the biggest possible number of participation and thus to evaluate the Kace software.

Thank you for your cooperation.

https://pucrs.qualtrics.com/SE/?SID=SV_2iBdHy6wmmLVdpb

This is really important in Enterprise environments, as security is critical. The best workflow that I can think of is:
1)Have an automated process label "ADaccountNoMatch" any user that is not present in AD as long as they didn’t have the label “ADoverride”.
>Have an automated process label "ADaccountDisabled" for any user marked as Disabled in AD as long as they didn’t have the label “ADoverride”.
>This should happen nightly **as long as user access would fail immediately if the AD account were disabled or removed**.
>An email with a summary of users labeled should be sent with the regular batch of Kace maintenance emails nightly as long as 1 or more accounts met the criteria during previous 24h.
2) Removal or changes to the Kace User could be done at any time in the future when the Admin is ready. One way would be the addition of a more feature rich Delete in the users table that would allow staff to purge the user from the system completely, OR would allow the user to remain in the system (label “ADoverride”) OR perhaps remain but be stripped of all other labels and system access.

Thank you for hopefully adding this in an upcoming release.

This is the configuration on the 'Reopen Ticket' email rule.
The first comment is the SQL statement, the second is the update query.

Hope this helps.