Tim Johnson

Adding in my own support, as we just started to look into using Organizations, and I'm coming across some funky access issues that seem to stem from how the Role-level permissions are built.

It seems the optimal solution (at least at the "Accessible Tickets" level) would be to set the "organization" and "group" permissions as checkboxes as opposed to radio buttons to allow for more control over exactly what an Agent can see:

• Assigned to this Agent only, plus:
  • Those within this Agent's assigned Organization(s)
  • Those within this Agent's assigned Group(s)
• All tickets regardless of Organization/Group membership

(the indented options would be checkboxes, while the outdented would be radio buttons)

The current issue is "Requested by end users in this agent's organization" and "All within this agent's group" are an either/or function. There's no way (that I can find) to give an Agent the ability to see tickets in both their Org and Groups without allowing everyone else in their Org to see all tickets in that same Org (via the "view all org tickets" permission set at the Org level). 

We have dept. managers who are both End Users and Agents in our setup. We want those managers to see the tickets requested by those within their Org, but do not want those End Users to see other's requests (since we have a single Instance and HR tickets are in there).

I believe by allowing us to define access to Groups, Orgs, or both at the Role level, we can make this happen. If there's a current solution to this, please let me know!

Would love to see this. Currently trying to find a way to remove a Follower from a ticket if that same person becomes the Assignee of the ticket. Otherwise, they'll start getting the email alerts that a new response is on the ticket when they're the one who sent it. 

Being able to reference Followers specifically in Triggers/Automations would definitely help with this.

(sorry for the wall of text)

I struggle to understand why "soft delete" is a thing if there's no way to sift thru the trashcan to find something you wind up needing, especially since the prompt to confirm a deletion just warns about assigned tickets and personal macros (and mentions nothing about reporting or KB articles). We have user accounts deleted as far back as two years ago still sitting there that we can't do anything with. 

As for suspending users, the "Suspend access" language implies it just prevents that person from logging in, but for many organizations (like ours) who utilize SSO, once their AD account is turned down, it inherently breaks authentication.

Since the warning is so light, nothing about it being irreversible (despite the word "delete"), and suspended users still show up alongside every other user just about everywhere, suspending users just adds to user bloat and just adds value to deleting them instead. You shouldn't downgrade a user from Staff to End User either, as that has it's own chaos. 

What I feel should be applied to deleting a user:

1. Add everything to the warning of what will happen and what will break
2. In that warning, offer to suspend instead
3. Move suspended users into their own separate list
4. Hide them from any Role, Organization, or other active list that shows users to cut down on that bloat

Or turn "soft delete" into suspending a user, and "permanent delete" become a multi-step process with varying levels of confirming that will actually delete someone.