Skip to main content

Problem

Gainsight CS displays execution history and related time-sensitive data using inconsistent time zones across different features, leading to confusion, wasted time, and the need for manual time zone conversions. Lack of time zone parity across features creates an unnecessary cognitive load for users trying to understand the status and timing of critical jobs.


When investigating why a specific user was missing on my end, I checked the execution time of the relevant Job (Salesforce connector).

  1. The Job's history showed the last run was yesterday at 7:00 AM.

  2. Knowing it’s a daily run, I expected it to have already executed today as it was 8:45

  3. Upon checking the Job's configuration, I realized the execution time was set to 7:00 AM PDT (the application's time zone), which corresponds to 4:00 PM in my local time.

  4. This caused me to mistakenly believe the execution was missing and required me to manually trigger the job; all because the displayed time was not in my local context.

Connectors → Activities UI


The root cause of this confusion is that I spend most of my time in the Rules Engine, where the execution history is displayed in my local time zone. When I switch to Connectors 2.0, the time zone shifts to the application's default. This broken experience forces users to perform "mental gymnastics" and consult external converters just to confirm the expected run time.

 

Proposed Solution

 

I request a feature to allow users to select the time zone for displayed data within each feature that shows execution history or timing (e.g., Jobs, Rules List, Rule Chain, etc.).

Ideally, this would function similarly to the Rules Engine → Activity view, but be integrated directly into the feature's interface, not as a separate activity section.

 

Rules Engine → Activity allows users to select the time zone for displaying data


Example Implementation:

Introduce a prominent UI element (like a toggle or dropdown) that allows the user to switch the display of time-stamped data between:

  1. Application Time Zone (e.g., PDT)

  2. User's Local Time Zone (The time zone of the user browsing the app)

 

Mockup: Allow the user to select the display time zone, dynamically adjusting all dates and times shown in the UI


Standardizing the display across all features will prevent user error, reduce support inquiries, and greatly improve the overall user experience.

#adminQoL

+1, this is unnecessarily complicated and tedious for admins. Standardization, as Romi proposed, would be a major improvement in this arena. 

Terms & ConditionsCookie settingsAccessibility statement