Decide whether application approvals are user-centric or machine-centric
I thought application requests were a user-centric concept.... whereby a user requests an application from the catalog and then installs it wherever he likes once it has been approved? If so, why are there triggers on the UserMachineRelation table in SQL to delete requests associated with aged UDA records?
I can understand why you might want to delete aged cancelled or denied requests, but why delete requests based on (constantly) changing UDA information? This makes no sense, as long as the user is still active in SCCM.
By indiscriminately deleting requests based on UDA, we often lose request history for requests that aren't all that old. Users then have to request the application again.
The worst thing about the whole process as it stands is that you cannot give anyone a definite answer to the question : "Does a user have to request an application once, or once per machine?". It depends on historical events which are difficult to explain to a user.
Frankly, I don't care what the answer is... as long as the answer is unambiguous.
SCCM Application Approvals commented
In fact, it might not even make sense to delete cancelled or denied requests since these requests are not necessarily dead. A user may wish to challenge a denial or even revive a previously cancelled request. If somethnig has been denied 3-4 times, maybe the history is relevant?
Assuming the model is a user-centric one, the computer that was used to lodge the request should be recorded simply for informational purposes. A change of computer should not affect that user's right to install the software. The software should only need to be approved once for the user.
You can't even change the computer name associated with the request in the event that a UDA relationship needs to change. Nor can you unapprove/revoke approved software in the event of an error or a user moving to another job, etc.
The application catalog was a great idea, but unless it is developped further (or MS support specific direct SQL manipulations or extend the web service functions) I would definately not recommend that anyone use it in a large corporate environment. It imposes far too many limitations.