Gainsight PX Internal Report Email Subscriptions

In addition to what you mention, I found out that everyone gets all the information in the report -even if they don’t have permission to view that information in Gainsight PX.

Please see (and perhaps upvote) my related idea to better control these reports: 

• In weekly adoption reports, only email portions that users have permissions to view New Idea
• 4 Votes

@Ashton , Under user profile > Account Settings > Email Reports; the users have option to opt-in and opt-out of the reports that they dont intend to receive. Instead of user having this option, you want the Admin to have the control of that?

An admin should have the ability to set the default subscriptions (to nothing if they wish). 

Subscribing a new user to multiple emails without validating that the user would get value from them is not a good practice. Example, the Developers who need access to Gainsight PX to get the Tag Key and test that events are being tracked, do not need the adoption reports. They are not in an appropriate role to subscribe to reports of this type.

@aharkut - What if the admin could set the default report for a user, but the user can later change subscriptions.

For example, if we know what product tags they work in,  they start with only the applicable reports.

@mmarques @Ashton 

We are working on being able to define access permissions for different products. Assume, if we provide “Product Reports” as an option - and users are given access to specific product reports. Then in their Account settings, they will only be able to opt-in for reports from specific products. Does that work? Because the ability to opt-in of specific report or not should be an user’s choice. Admin should only be able to control whether the user has access to reports at product level or not.

Thanks,

Abhilash

@aharkut - Sounds good to me.

Update: I am having to setup a blacklist with my IT department to block all “Gainsight PX Reporting” emails. This is truly unfortunate but needs to be done with the number of emails we are getting.

Unfortunately I have too many staff and too many products (and there are too many emails per product) that we are not able to use the workaround of “manually unsubscribe” or wait for the future state of users being assigned to individual products. 

I will state again the critical defect is: Users should not be auto subscribed to emails upon user/product creation. This needs to be removed from the product ASAP. 

This seems like a great opportunity to use an engagement to confirm user’s desired email subscriptions. That is if you really want to show off what engagements can do ;)