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.