[[Template core/front/profile/profileHeader is throwing an error. This theme may be out of date. Run the support tool in the AdminCP to restore the default theme.]]
Great post! I like the idea of having 3 boards. It can be difficult separating actionable from non actionable alerts. A few questions... How do you handle alerts that are generated via email from outside of Automate? For example, Meraki alerting if an appliance is down. An email will generate a ticket for a failure notice, but then a separate ticket for a success notice. Do you automate these types of tickets as well? Do all of your techs look at the same service board? Or do they only work tickets that are dispatched / assigned to them? Are your workflows / reporting primarily built around ticket summary description or Type, Subtype, Item. Would you mind sharing some examples of what your ticket Type, Subtype, and Items are for manage? In regards to syncing devices, I am testing having 2 additional locations at each client for "DoNotBill" and "Offboard". Then, I will configure the CW Manage Plugin agreement mapping to target specific client locations, not the whole client. Any devices that should remain under the Client, but not count towards their agreement will go in the "DoNotBill" location and any devices that should be offboarded and have any software removed will go into the "Offboard" location. This way, the devices stay under the same Client when syncing configs to CW Manage. It is a bit more to manage and set up, but currently we are moving devices to an entirely separate client "PendingDeletion". Doing this breaks the config sync, since the Client is changing for the device.
Giving them access to the thick client at all is going to be a security / privacy concern. For example, all script names and search names are visible regardless of permissions. I wouldn't call risk of SQL injection a small fear. Any level of script building access is a potential security risk. Monitoring won't help you if the damage is already done. If I were you, I would create a client in Automate and start building out the permissions for a test user account. Then you can log on and see everything they'll have access to.