Currently, there are several variations on common components in the K1000 admin interface that cause confusion & force workarounds. Some implementations of the OS selection force you to go in and revise all Custom Inventory Rules every time a OS update is released. Some instances of scheduling force the creation of multiple items (alerts & Wake on LAN events, for example) because they are needed multiple times in 1 week to match a patch schedule. These are the different implementations I have seen:

1) OS Selection-
Software Inventory: (also used for custom inventory rules) forces admins to select supported OS versions to the specific point update or Service Pack;

Scripting: Allows for individual OS selection like above, but allows selection of "All Windows" or "All OS X", or even "Leave blank to deploy to ALL operating systems";

Patching: Allows for the same options as Scripting, but with a different layout/selection list.

2) Alerts-
Patching: Alerts are restricted to 255 characters, and will not allow additional characters to be saved in the message box;

Managed Install: I believe Alert length is limited, but you can save an alert message with a seemingly unlimited length. It will just not be displayed in full;

Standalone: Alerts are limited (somewhere between 400-500, if I am correct) but again, the UI does not warn you if you put in too long of a message, it just clips it when displaying on the client/agent.

3) Scheduling-
Wake on LAN: Allows only "Run Every...(day)" or "Run on the...(1st)" options;

Scripting: Allows "Run every ... minutes", "Run every ...(day)", Run on the ...(1st)", or "Run custom";

Patching: Allows "Run every ... hours", "Run every ...(day)", Run on the ...(1st)", or "Run custom";

Scheduled Reports: Allows only "Run every ... hours", "Run every ...(day)", or Run on the ...(1st)";

Alerts: Allows ONLY "Run every ...(day)";

Email Alerts: ONLY “Frequency (15 min/30 min/Hourly/Daily/Weekly/Monthly);

MI/FS: Uses only a ‘live’ deployment window (cannot specify a future date).

I would like to see these three aspects of the UI be more consistent across the various functions. It is frustrating to schedule multiple things to be in conjunction with each other, but then have to create multiple scheduled WOL events to match one patch deployment (for example) only because of the scheduling syntax.

For the three options, I would recommend the following models:
1) OS Selection: Model all instances after the Scripting implementation.
2) Alerts: Use the character limit of the Standalone alerts, but give feedback about character limitations (including a JavaScript live count as you type)
3) Scheduling: Model all instances after the Patching/Scripting implementations, but allow for switching between minutes/hours on the first option.

This way we could easily and quickly run a script, deploy a software package, or initiate a patch schedule (for just that machine) right from the machine list or machine detail page. Would be extremely handy, browser-agnostic, and save a lot of time.

For example, if you have the two free Bomgar licenses and chose the hosted option you could initiate a Bomgar session with one or two clicks from the machine page without sending an e-mail message. Or if you are working on getting your patches up-to-date you could focus on one machine and kick off a patch schedule run for it, again with one or two clicks without leaving the machine page.

When a smart label is created, and even though testing it returns a close to accurate result directly from the database query, the "View By" drop down in the inventory for that smart label, doesn't start to get populated until the next agent checkin.
Since the information is mostly in the DB, I would suggest that the View By would get populated from the existing database, and update the contents of the smart label as needed upon next agent checkin.

(currently, if testing a smart label, after actually creating it, you would have to wait some 15 minutes at least just to figure out if it's doing what you expect from within the "View By" category

When building a smart label, queries are done independant of each other. So If I make a label that says look for This program and this version, it will check the full mahcine inventory for that software, and then check the full inventory for that version number. Instead, it should only check the version number of the software I selected. This cause issues when more then one program has the same version number as another you want to check for.
Example. A machine has 32bit java version X and 64bit java version Y. I want to see if a machine has 64bit java and it it is NOT version X. Then the smart label will find is has 64bit java in the software inventory and the version X from the 32bit Java, and then will not apply the label.

On the inventory side, I have some labels (for rooms) within label groups (for buildings) within label groups (for campuses). This presents a nice multi-tiered menu in the inventory "View by": filter. I would like to replicate this on the asset side of the application, but I can't seem to get it to work. I have tried three separate asset types (Campus is parent to Building, which is parent to Room), that didn't work as I only get the Campus to show up. I tried using Location as a parent to itself, but that presents ALL locations in alpha order at each level of the hierarchy.