Hi Forrest, I've messaged you back now. Thanks Marie

Seconded!

Hi Everyone I've hit an issue today that has highlighted 3 issues to me related to use of time-based routing in an escalation chain. I realise that alert routing is 'first satisfied' so you have to squeeze all your required actions into each rule, but what I did not realise and it was not made clear in documentation, only by testing, is that the escalation chain works in list order, not logic not cumulative. In the example below, the second set 'everyday' superseded the third 'Mon Tue Wed Thr Fri'. 1. The documentation doesn't cover this, so nothing tells you that it is neither cumulative or processed in order 2. Being processed in order there is no index or priority order to show you this is the case 3. There is no safety mechanism to prevent, or warning to advise that you are configuring something that doesn't work At least one, and I'd suggest all three of the above should be rectified. As a development request, it would be nice to have cumulative stages as I need to use identical stages across different customers to operate my out of hours service, but also need to include the customer. This would make it more MSP and multi tennant friendly. Thanks Marie

Hi All I've raised a ticket and been told that it isn't possible to stop someone seeing service requests. This presents me with a big issue as an MSP as I don't want the customer base to see improvements that I may productise or features that require additional costs such as LMConfig. Is it possible to add a tick box in the user role to remove this feature? Thanks Marie

This would be great as a device tree 'lock' button that you had to flip the switch to be able to move and the flip it to lock again when you've finished. Like Mosh said, drag and drop would be a pain if you had to acknowledge every single one if you were restructuring.