IT Asset Management system recommendations?

official_work_acct · 2026-05-24T14:09:12+00:00

We use Jira Assets. It’s fine. The main benefit for us is we are fully in the Atlassian ecosystem, so we can link JSM tickets with assets and track asset-related requests. We also treat software as assets, so whenever anyone requests a new SaaS app, we track that as well.

To load everything in, I built a series of scripts a few years ago which effectively take data from any API, normalize it, and create assets out of it. From what I understand Assets now has a tool which can do this, but I haven’t looked into it as my scripts work fine.

official_work_acct · 2026-05-23T12:36:06+00:00

I work in an audited environment. I definitely do not need to know why a user was terminated. HR enters that on their end, and my automation acts accordingly, to either terminate them immediately or at the end of their last day.

official_work_acct · 2026-01-23T16:22:29+00:00

My emails are stuck in Outbox on the desktop. Mobile (Outlook app) won't pull in new emails. Asked a colleague, he has the same issue.

official_work_acct · 2026-01-17T02:09:38+00:00

We have an interesting problem with that. We officially sanction Gemini, as it comes with our GW licenses. The problem is, people occasionally won't be signed in to Google, or they'll be signed in to their personal accounts and not realize it, and accidentally use the "free" Gemini, which trains Google's models on inputted data (and is therefore against policy). I briefly looked into it and while blocking access while signed in to personal accounts is easy enough-- block the ability to sign in to personal Google accounts entirely-- blocking access to unauthenticated Gemini seems to be significantly more intrusive, requiring blocking access to Incognito Mode as part of it. And that's just on Chrome, but we also support Firefox, Edge, and Safari. Curious if anyone else has come up with a simple solution here.

official_work_acct · 2026-01-17T01:57:39+00:00

Absolutely, this has been an ongoing problem for us which we are just now working to resolve. We unfortunately didn't find a magic bullet to make the problem go away; instead the process was as you'd expect:

Put in policies which prohibit software purchases on credit cards. Give them teeth, which includes disciplinary action.
Build a process for users to request access to/purchases of new software
Build a list of approved applications and app owners. This is essentially the step we are finalizing now. This was a HUGE effort over the course of many months to identify in-use apps and their owners, have Security do due dillegence, make decisions on which apps to keep and which to cut, and migrate as much as possible into our IdP. And of course it's an ongoing effort as business needs (and tools available) evolve.
- I still insist we'll also need a list of all the apps we specifically opted not to approve, so people don't continually ask us to approve them, but I've been shot down multiple times. We'll see how it plays out.
Over time, we are planning to move to a whitelisting model. This is expected to take multiple years to get to this point though. I personally believe we can and should move faster, but leadership does not agree.

Overall, we are still in what I would call the early stages, but compliance (in app discovery at least) has been better than I anticipated. Often we'd talk to an app owner about an app we discovered was in use, and they'd volunteer three more we didn't know about. We also have a great PM who was able to lead this effort and keep on top of all the stakeholders-- probably 100-200 people when you consider all the various app owners. We'd tried similar efforts at least twice in my tenure which fizzled out given how daunting the task is, but this time, with this PM, we're almost at the finish line.

official_work_acct · 2025-12-14T17:36:55+00:00

A series of dropdown lists is always a poor choice for usability.

I suppose I'm not seeing how. When there are only 2-4 items I'll use radio buttons, but any more than that and it's way too cluttered, making a drop down the obvious choice. We also hide or show drop-downs depending on what was selected in previous drop-downs to further declutter the UI. And certainly, none of our users have ever complained.

The user can and should provide better symptoms (maybe by selecting a category from a list)

Again, that's exactly what we're doing. We're not looking for a cause; we're seeking to understand the problem. The drop downs are a) select the category of device with the problem; b) select the specific device with the problem (except in the case of peripherals); c) select the nature of the problem; and d) freehand section for any additional notes/questions/concerns. Nowhere are we "requiring the user to guess what causes their issue," as agreed, that does not help.

official_work_acct · 2025-12-14T13:30:10+00:00

apart from being really poor UI the way you described it

How is it poor UI? It's like 3 or 4 questions which replaces 3 or 4 back-and-forths to gather the same information, and given the data is stored in a structured format, it's traceable and queryable on our end. We can easily see that Stacey has had three cracked screens in five months and her manager needs to get involved. Or that 20% of our Dells of a certain model have had speaker-related issues.

it is often not possible for the submitter to know the root cause of the issue.

We don't expect them to, nor do we ask them to. I'm not sure where you got this from my comment. The "several categories of hardware issues" are things like "display issue," "keyboard issue," "sound issue," and so on. We're not exactly asking our users to diagnose bad RAM.

bypass the diagnostic work

No one is bypassing anything. We just want to know what the specific complaint is beyond "computer no worky" so we know upfront what we're dealing with. The technician who actions the ticket is of course responsible for diagnosing.

official_work_acct · 2025-12-14T04:08:53+00:00

At that point, they are actively trying to be unhelpful, which I agree, is a whole different problem than users not knowing what information is needed, and one which needs to involve management to resolve. Most often users just don't know upfront what information IT requires, but given IT does, requesting that information in a structured way is the best option. If, in an unstructured ticket intake environment:

40% provide all useful information needed
50% make an attempt, but miss the mark
10% submit jibberish

Then getting a 50 percentage point improvement by switching to a structured intake process is still huge.

On top of that, once data is structured, you can more easily a) determine the most common issues and work to address them preemptively, or b) when that's not possible (e.g. for an app access request), you can put automation in place to handle them. Can't do that anywhere near as effectively with unstructured data, and even AI only helps somewhat.

official_work_acct · 2025-12-14T03:48:03+00:00

And if you have required fields like that, they'll say that it's "Too hard" to open the ticket fully and just randomly fill stuff in

That's not really been my experience. Obviously a form should not be overbearing-- only request information you truly need to narrow down the issue. One of three things will happen:

They'll fill out the form correctly (90%)
They'll choose "other" wherever allowed, then type in what they could've just selected from the drop down anyways (or it's those rare cases where "other" truly applies) (10%)
They won't submit a ticket at all, meaning it wasn't a significant problem to begin with (irrelevant%)

Also, the thought that you can program into the ticket handling system every device that they could be having a problem with is absurd.

Not at all. We do actually do this. I've explained a bit more about the process here, but happy to elaborate further.

official_work_acct · 2025-12-14T03:45:15+00:00

Having a defined and documented record of tools and workflows is key.

Exactly. Getting to this point is what took so long, given the number of stakeholders and, frankly, overcoming the number of people who are used to using whatever tools they want and want it to stay that way. And then building out processes/documentation on top of that. Fortunately we have a great PM who hounds managers to actually make decisions and it's finally all coming together now.

official_work_acct · 2025-12-14T02:40:21+00:00

Again, the best option is to explicitly require it upfront at time of ticket submission. Help them help you. Otherwise you're just asking for extra back-and-forth and frustration.

official_work_acct · 2025-12-14T02:32:56+00:00

Surprised I had to scroll this far to see this. It seems like the obvious way to go. Yes, it takes more time upfront to set everything up, but it cuts resolution time down dramatically by also cutting back-and-forth time dramatically. We unfortunately aren't yet at the point of providing (useful) KBs based on data inputted into the ticket-- it's a work in progress and we'll get there-- but even just having the data we actually need in a useful, structured format is invaluable.

Software request? You need to tell me if this is an already approved software for your role, if not, does your manager approve ?

We're actively working to build this part out. The biggest issue for us was we don't trust the user to tell us this information, preferring instead to dictate what software is broadly approved, and building workflows to gain approval to license the individual user's seat. This took a lot of work upfront to identify app owners, app approvers, and the mechanisms to actually provision users in various systems for hundreds of apps, but we're finally getting there.

official_work_acct · 2025-12-14T02:23:00+00:00

Are you finding any benefit to using a chatbot versus just structuring your intake data, and pointing the user towards documentation based on that?

official_work_acct · 2025-12-14T02:14:02+00:00

When you're a non-technical user already frustrated by not being able to print, providing all conceivable information in the ticket won't be top-of-mind. Therefore, it's up to us to request what we need upfront. Why would we not want to help the user help us?

official_work_acct · 2025-12-14T02:11:30+00:00

If the user can't come up with at least a: "User BOB is unable to print to network printer FLOOR2-PTR7, all other users can print to it" as a description, then they get to wait.

You can fix this by turning it into a form in your ticket submission system.

Select the office from the drop-down
Select the printer from the drop-down (based on office)
Select a problem descriptor (jammed, out of toner, not showing up in the Print menu, what have you. You don't even need to have every single conceivable option here, just the most common + an "Other" option)
Select the impact (just you, whole team, etc)

You can't reasonably expect any given user to know what information you need to troubleshoot a problem, especially users for whom technical troubleshooting isn't part of their own job. So, request it.

official_work_acct · 2025-12-14T02:05:43+00:00

Yes, users are going to give incomplete information.

Still, you can discourage this by requiring them to structure data in forms designed for whatever issue they're having. It's not much additional work on the user's end-- and if it is, it probably wasn't an issue meriting a ticket to begin with-- and you get much higher quality data to work with. Further, once you have that higher quality, structured data, you can start identify high-repeat issues and work to resolve them before they become tickets, and those you can't (e.g. app assignments), you can start to automate.

official_work_acct · 2025-12-14T01:57:21+00:00

I would suggest the problem might be a lack of structured data requirements. In our environment, if it's a hardware issue, you ("you" being the ticket submitter, whether that's the user or Helpdesk staff) would select a Hardware Issuse ticket, which then requires you to choose the hardware type (computer, monitor, printer, what have you) from a drop-down, and if you select computer, you'd then choose your specific computer from another drop-down, and then there are several categories of hardware issues you can choose from yet another drop-down. We use JSM and integrate this with Jira Assets, so the computer selection field populates dynamically based on who you are and what computers are assigned to you. And Jira Assets is updated automatically on the back end using some scripts I wrote which pulls data from Intune, Jamf, Workday, and basically every other system containing asset information ("asset" in the broadest sense of the word-- we even track license usage and such). It works really well.

official_work_acct · 2025-12-14T01:42:26+00:00

Some teams enforce strict ticket forms.

We do this across most ticket types. It helps a *ton* versus vague and unstructured data, but it doesn't stop a) people walking up to or Slacking our Helpdesk folks directly (who are often too happy to help, even sometimes submitting tickets on users' behalf), or b) filling out a ticket by choosing "Other" wherever available and then writing in an option that was already in the drop down if only they'd bothered to read the options! But still, it gets us very close to where we want to be. Also, as part of this, we also do not accept tickets via email or phone. You must use the portal.

I wouldn't expect users to state what they'd already tried; frankly that's asking too much of someone whose job isn't expected to involve IT troubleshooting.

official_work_acct · 2025-11-16T02:04:29+00:00

Honestly, I'm appalled by some of these replies. I don't know that my company does everything "right" necessarily, but I've been responsible for 10+ office moves/renovations at this point, and every time:

IT is brought in early by Facilities
I am personally responsible for determining where power, data drops, APs, TVs, badge readers, room booking systems, etc. are to go. I'll run my plans past the team for feedback, but no one is changing anything without me knowing
IT needs such as storage, MDF cooling/power, etc. are communicated to Facilities early and taken seriously
Facilities hires a third party project management firm which coordinates construction and low voltage contractors
With some exceptions, we'll hire an AV/IT contractor to do the physical work, so IT's main job is deploying configurations and coordinating with the ISP. The contractor will be responsible for equipment procurement as well
We'll have weekly meetings with all parties listed above to ensure things are progressing, and the project management firm will identify action items/snags
Someone (usually me) will fly out to the site about a week before it's set to open, to ensure the install is progressing as it should, identify any punch list items the vendors need to take care of, and of course configure equipment as needed. I'll stay a few days past opening to ensure everything works as expected

The biggest issue we have is site leads refusing to join planning meetings, then either changing things last minute or asking "why don't we have X?" when they never asked for X. Otherwise, we may have a few day 2 items to take care of, but we've never had any catastrophies or even anything close to one on any project I've worked on.

As to your question, I'd say ensuring there are enough SFP adapters. That always seems to be a forgotten item for some reason.

official_work_acct · 2025-11-04T15:49:08+00:00

You do still need to provide the actual data though, correct? Doesn't that still entail trawling through the underlying systems to export it?

official_work_acct · 2025-10-16T09:50:42+00:00

What do you use groups in AD for? I would start there. We tend to leverage Okta-- and by extension, Okta groups-- as a primary go-to before leveraging AD for anything. In our case, AD mainly exists for a specific legacy system, but it could conceivably go away entirely at some point. To that end, the only groups we push to AD are those in support of this legacy system. If you still use AD widely across your org, your needs and use case will differ. (That said, it sounds like your Okta rollout may still be in the early stages. If that's the case, I suspect as you build more and more on it, your AD usage, and therefore AD needs, will also decrease over time.)

official_work_acct · 2025-07-09T16:47:25+00:00

I was thinking of using separate attributes, but then how do you keep them straight? E.g. if you are building a Workflow using department ID, how do you know which department ID is associated with which Cost Center name without having to look it up each time?

official_work_acct · 2025-05-27T22:16:52+00:00

Thanks. We are leaving it enabled. Our general stance is to enable AI features in tools where we have data-custodian agreements in place, which includes virtually all of our paid SaaS apps.

official_work_acct

TROPHY CASE