I was wondering if anyone has any suggestions on how to handle sensitive tickets which you only want one group to be able to see, such as in our case, Security tickets.
Our use case is - we want to be able to have our users log a Security ticket which is only viewable to a portion of our Agents (Security experts & Major Incident Mgrs). Our current solution sucks - we have had to make the entirety of our FS restrict access by group, so they can only view tickets assigned to their group. This is somewhat a workaround, however it means that access and visibility for all non-Security tickets is poor and I run into a whole host of complaints and problems around people 'losing' tickets as they get moved around the support teams. It requires a lot of admin, trial and error, and is ultimately not remotely scalable.
It seems ridiculous that there is no way to restrict access to a specific group, but I have to instead restrict access for every single group.
Wondering if there's any suggestions that could allow us to keep the sensitivity associated with Security tickets without having to have such tight restrictions on every other group.
Our current design of access control is not based on restricting access like you have asked for. What you have adopted is the workaround we provide for your use case, where the tickets of a specific group/s (Security experts & Major Incident Mgrs) should not be viewed by any other group.
However, if you would like all the other groups to view each others' tickets, you can add the corresponding agents to the agent groups as Observers.
Agents added as Observers to a specific group can view tickets, assets, changes etc that specific group owns, based on their Roles and Scope within Freshservice, but not perform any edits/modifications on the same.
Add Members/Observers to Agent Groups - https://support.freshservice.com/support/solutions/articles/50000001086-add-members-observers-to-agent-groups
Let me know if you need help setting this up and I shall help you out
Unfortunately, only if you are in the Forest plan. :(
Thanks for your response. What you have described we are currently using, but I think a 'workaround' is a bit of an exaggeration. It means that we had to change the fundamentals of our entire helpdesk, restricting access by default and having to manually grant access through adding to Observers. This becomes exponentially difficult to scale the more people and teams you had, to the point where it will become such a large admin task/maintenance that it will be an uncontrollable beast. I have been told that this isn't something a lot of customers require, but as FreshService continues to grow into larger and larger Enterprise organisations, I imagine every single one of those will have requirements to have red tape around Security tickets. Hopefully this is something at least recognised as a requirement so that it doesn't dictate such a narrow scope for how we can use FreshService.
This problem may be difficult to solve, but there's an enormous demand for a solution.
Many institutions need to upload documents to a secure repository that is associated with a service workflow. The need arises any time a requester must furnish credentials or personal information to establish an account, transact business, or verify identity. My institution encounters this problem. Currently, the request can flow through a FreshService workflow, but the supporting documents (Driver's License) must be uploaded to a secure repository which is shared with the appropriate people outside the FS workflow. This is cumbersome and takes longer than it should. In addition, the requester may not know who the approvers and other agents are, and, so, cannot share the secured URL with the right people in advance.
We had a similar problem with having to restrict access to one teams tickets where they could not be seen by other remainijg teams. We initially had the same issue with tickets going missing between teams by using groups to restrict. As a workaround, we created one group for the restricted access group and one big group with each agent for all other teams that were not restricted to see each others tickets. We then created a custom dropdown list in 'Form Fields' called subgroups on the ticket field properties and added each team as an option to organise the tickets as per groups option had done previously. We can use the workflow automator to place tickets in subgroups or add manually. It worked for us and we can report etc... It would be much better to have an inbuilt way of doing this.
We had a similar issue where we had to restrict access to tickets between two teams. The only way to do this was to restrict access to tickets in your own group and it did cause us the same challenges with tickets no longer visible between teams. We therefore created one group for the restricted tickets and we created another group with all remaining agents to view tickets. We then created a custom dropdown list in 'Form Fields' and added each team as an option and subgroup whcih coudl be applied on each ticket in the field properties. We then used these sub-groups rather than the main groups to organise and report on tickets in the same way. It helped in that situation. It woudl be good to have a btter inbuilt way of doing this though.