I'd 2nd this.  

I tried to setup a SessionGroup to solve the Recently accessed listing, hoping to use a mixture of LastEventHost = $USERNAME, and LastEventType = 'InitiateJoin' and LasttEventTime > $@DAYSAGO, but couldn't find any suitable reference properties.  Perhaps the team can provide a suitable Session Group example.

I think the Favourites could easily be achieved by setting CustomPropertyN and creating a suitable SessionGroup - but again, for simplicity it would be nice to have this built in.

Not sure this is practical.

- Not every support user (in our environment at least) has access to Administer Triggers

- We often only want to be alerted when a single Access Session (re)connects - (not our entire fleet of machines) - and having to manually create/edit a Trigger for each individual Access Session would be cumbersome

That said - I'm sure someone could easily create an Extension that was bound to the Access Session (Rightmouse Click) Menu to create/edit enable or disable an individual "Alert when (re)Connects" Trigger - therefore adopting EBell's suggestion, whilst delivering ease of use.  Perhaps that someone might be the Developers? 

This would be extremely handy - especially being able to set/control this on an individual Access Session/Client basis.  We have a number of Access Session machines that are offline for long periods of time (in some cases days or even weeks), and may only be online for an hour (or less) at a time.  Attempting to schedule work on these machines is extremely difficult - so this Notification Feature would be extremely handy!   

I've up voted this!

In our situation, we have 100's of Access clients, which are Session Grouped representing our different Clients and Locations.  We generally have to up date 5 or so individual Access Clients at a time, as we have no idea of progress if we attempt to update an entire Group (which might contain anything up to 100 clients).

We generally resort to reviewing the Timeline to see if the Reinstall Message has been sent to a particular Client.  This means checking individually.

We then resort to checking whether the Access Client has disconnected and reconnected.  If the version hasn't updated and its had a disconnect and reconnect after the Reinstall Message, then we conclude the Reinstall has failed.

We have a follow up process, using a Session Group with subGroup Connected, then Client Version - so we can see how many Clients remain on the old version(s) - and generally periodically (re)attempt a Reinstall as needed.

It would certainly be nice to know (at a glance), the current state/stage of a Reinstall for each Access Client:

- Reinstall Queued

- Reinstall Downloading Update % (we have a few slow connections that will timeout from time to time - so having some restart logic here might be nice)

- Reinstall Download Complete (once its downloaded and the MD5 continue to match - why send the Client another update)

- Reinstall Updating

- Reinstall Update Failed (with Reason)

Anyway - just my thoughts - and obviously up voting this Feature Request.