Assets - Add Distribution List, Shared Mailbox, Security Group and Generic Accounts

You can create your own asset types and use it. I have made a “License” asset typ and use it to assign/create on the fly with API when it’s requested. 

Take the name from the service item when I create the asset and assign it to the ticket and the requester. 

oo

This is a solid request — adding support for distribution lists, shared mailboxes, security groups, and generic accounts would solve a big gap in Freshservice asset management. Many organizations use these non-user identities for ticket routing, mailbox monitoring, automation triggers, and internal workflows, but they currently have no clean way to track or manage them as assets.

Allowing these account types to be added as assets would help teams:

• maintain accurate identity/access inventories

• track ownership and lifecycle of shared mailboxes

• monitor permissions assigned to distribution lists and security groups

• improve audit readiness for access controls

• reduce manual tracking in spreadsheets

This becomes even more important for teams that operate under compliance frameworks where every identity — even non-human ones — needs to be documented and managed.

Organizations operating under strict regulatory oversight trust our U.S.-based IT systems assessment to meet security, data residency, and audit-readiness requirements. Better visibility into shared accounts aligns directly with that need, and having first-class support for these asset types in Freshservice would help regulated teams stay compliant without workarounds.

Hopefully Freshworks considers adding this, because it would make asset management far more complete and reduce unnecessary friction for IT admins.

Yes but then you would have to manually add in all of them. Rather than have them automatically update when they are created in Azure or on-prem AD. 

We have THOUSANDS of each. Not feasible to keep maintained.

Well put. Plus at the moment, the current suggestion is to make them requesters. Which is not a good workaround as this only ends up getting misused. We have had people use it to approve their own requests from mailboxes they had access to. We try and ensure that no shared mailboxes or generic accounts are added as requesters but it is hard to keep updated with so many users and mailboxes.

If we could have a way to import them into their own separate containers and that way they cannot be imported as requesters because then it would be a duplicate record, that would be so much better and easier to maintain.

We do have some slight exemptions where we allow SOME shared mailboxes but they are few and far between.

So when you add a user to a mail box in Exchange online you like  to update fresh. 
I would do it that Fresh adds the user to the mailbox group etc and adds the user to the software/asset. 

Assets are 1:1  but software are 1:to many. 

Approvals should be hard coded in the system, reporting manager or fixed in a custom object or workflow. To be able to select someone to approve a request screams for disaster even if it’s the easier way out. 



 

We do not have simple organisations. We look after a whole state of many organisations. so have a lot of customers. A mailbox could have multiple approvers and therefore cannot be hardcoded. This is written in on-prem AD or in a notes section of the mailbox in Azure. It requires either an owner approval to get access or someone high up at a particular rank.

Therefore, hardcoding in approvals into Freshservice does not make any sense in our case. While that would be nice, we also have people moving around very often between locations so owners and approvers can change a lot.

Approvals were also not part of the original feature suggestion either. We just wanted a way to import who had access to each mailbox/group type and the name of each separate type so that it was easier for someone to find and select and also easier for our Service Centre to process the ticket and grant the required access to the correct type of mailbox/group. It also allows for better auditing, if we do not have to use an auditing tool to work out what someone was added or removed from and it was just in an activity log in the person’s record of Freshservice, that they were requested to be added or removed from something (and the ticket was there listed in their customer record) AND the audit of that happening was in their customer record as well. Therefore, you know the ticket has been processed or if someone was removed incorrectly from something.

It makes for better visibility and auditing in a large organisation.