@dan_wiegert I’ve asked for this as well. If something is not working I’m usually clever enough to figure out there’s an error, but if my error message just reads “error” I don’t really get any new information from that. Error codes are useful to send to support but it would be even better if you could either lookup what the code meant or you had something more descriptive.

@bradley I think we can both agree that there is no “easy button” in gainsight, and this ask is essentially the direct opposite. If it is possible I think it would be beneficial the have tiered logging exposure based on a permission bundle based setting that would allow superadmin level users to select error/logging granularity settings. the first level (Standard) would essentially present logs and errors per gainsights current, universal logging granularity. The second level could be Detailed and expose request id’s on failures along with the error message, and the third level could be Advanced, which could expose the full content of backend error logging.  I also think that all logs should expose request id’s within the product error notifications and that the generic “failed due to server error” message should be removed from the product because it provides almost zero actionable information and never includes a request ID.

*my 2 cents*

Yea, there is no easy button for sure, but there’s probably degrees of complexity. I think you just expose the error data in a way that can be expanded visually if an admin wants to look at it, or ignored if they aren’t as technical or don’t want to be bothered. I think for me this is one of the rare cases where permission sets for a feature would be gilding the Lilly.

@bradley  Even if this was a back end feature option on NXT tenants that wasn’t initially exposed in the product, but could be enabled if requested I think that it would be a great feature to empower technically minded admin teams, and it might even shave a few troubleshooting steps off of certain interactions with support. 

100000000%

Some of us GS Admins have a background in technology. I myself was a Unix/Linux Engineer for the a large chunk of my career. Being an application admin now, I feel very limited - even crippled - without the ability to parse log files.

I believe this would be massively useful - not only for platform/backend type logging, but everything including the execution logs for things like rules, programs, DD sets, X-Org migration, Sandbox refreshes, etc.

I recently shared this with @ophirsw as one of the items I believe limits Gainsight’s capabilities as an enterprise-ready platform specifically as it relates to rule execution logs, but the conversation is definitely expandable:

Rules Engine logs need to be simplified to require less admin analysis time, for a few reasons:

1. Field Mapping - GS fields don’t contain their labels on column headers on the Action tabs...they contain ID labels...(see screenshots below). There is a mapping key on the Execution Summary tab (shown below), but it’s so time consuming to flip back and forth between tabs, especially when there are multiple columns in an action.

2. Length of Log Storage - Just because a rule completes doesn’t mean it achieved the desired result. Sometimes we don’t hear about a problem with a CTA or a data point until weeks later. Logs vanish after 30 days, limiting our window to backtrace. Logs should be available for a lot longer than 30 days.

3. Individual Logs Per Asset - When you do have to go and backtrace to see what happened and when, you have to download individual files from each rule - that gets very time consuming if you are having trace back through multiple days to find out where the data point was changed and/or issue occurred. Having consolidated execution logs available to view and export (perhaps via Analyzer) would save admin time and potentially expedite problem resolution. (For the Linux nerds like me out there, think of the /var/log files:

At a minimum, just consolidating all queries and execution log stats into a single spreadsheet per run would be a major improvement. We have some rules with 10 or more tasks...today each one of those requires a separate file download per query, per rule, per run.

And I discovered recently that rules that update Salesforce fields don’t even product results in the Execution Log! They produce individual execution logs PER ACTION:

Troubleshooting the Gainsight platform has not gotten easier, over time - it’s only gotten more difficult and time intensive.