Skip to main content

Idea Pipeline

5636 Ideas

romihache
romihacheVIP ⭐️⭐️⭐️⭐️⭐️

Standardize Time Zone Display Across ApplicationNew Idea

ProblemGainsight 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 processes and workflows.When investigating why a specific user was missing on my end, I checked the execution time of the relevant Job (Salesforce connector). The Job's history showed the last run was yesterday at 7:00 AM. Knowing it’s a daily run, I expected it to have already executed today as it was 8:45 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. 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 UIThe 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 dataExample Implementation:Introduce a prominent UI element (like a toggle or dropdown) that allows the user to switch the display of time-stamped data between: Application Time Zone (e.g., PDT) 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 UIStandardizing the display across all features will prevent user error, reduce support inquiries, and greatly improve the overall user experience.#adminQoL

bjoern_schulze
bjoern_schulzeHelper ⭐️⭐️⭐️

Privacy / Data erasure policy: Fully remove a username from the community after account removalOpen

inSided stated in their data erasure policy that when a user account is being removed - in order to anonymize a user:“no personal data is available anymore, nor in the system nor in any backup - the user record can no longer be retrieved” “their content will be left intact to avoid damage to the community - but the attached user record is now Anonymized”But unfortunately that’s not fully true. What happens:A user (in this case “Spreeandre”) registers in the community, posts topics and / or comments Other users interact with this user by quoting or mentioning them The user then asks for his account to be deleted After the account is deleted, the user’s own content is being anonymized But: The username in mentions and quotes won’t be anonymized → inSided’s claim that “no personal data is available anymore” isn’t true because it is still easily possible to connect the anonymized content to the original username (which can easily be found via Google)The reason why this happens is:The username is being inserted as a plain text so after a posting was published, the username is a fix part of the content The correct way of doing it would be to load the username from the database every time the content is being loaded → So when a change is being made (e.g. username change or user is being removed), the data will be loaded from the database and instead of the plain text username the updated “Anonymous” (or changed username) will be displayedThat’s why our proposal is:In order to really ensure the “right to be forgotten”, it is necessary to change the way the usernames are being displayed in mentions and quotes. It is necessary to pull the data from the database instead of inserting usernames in plain text.If this isn’t done, inSided customers are violating the GDPR because they don’t fully remove the identifiable user data from the platform automatically (and doing it manually by editing every single piece of content where an anonymized user was being mentioned or quoted is a very time-consuming and error-prone work around).

ariveral
ariveralContributor ⭐️

Automatic Error Notification for Incorrect URLs in Audience FiltersNew Idea

Problem:Today, Gainsight PX allows users to target engagements using specific URLs within Audience → Rules. However, PX does not currently validate whether an entered URL is correct or still exists in the product. Because of this, admins may unknowingly configure engagements using outdated or invalid URLs, especially in products where page structures change frequently.As a result, engagements fail to trigger for the intended audience, which leads to missed responses and inaccurate reporting.Use Case:Our own product experiences constant URL changes due to ongoing UI/UX updates, new page releases, refactoring, and A/B test variations. Because there are high volumes of URLs, it is not feasible to manually track every single change.This has led to multiple instances where PX engagements set for specific pages did not fire, because the URLs had already changed. Consequently, we have received complaints about low NPS response rates and low engagement metrics, which were later traced back to invalid or outdated URLs in the PX audience filters.Proposed SolutionIntroduce URL validation and notification capabilities within the Engagement Audience Filters. Specifically: Real‑time validation: When a user enters a URL in the audience filter, PX should detect if the URL does not exist or cannot be found on any tracked sessions. Warning message or error state: PX should display a clear visual warning such as:“The URL entered appears invalid or has no associated user sessions. Please verify.” Optional notification or proactive alerts: Email or in‑app notification when URLs used in active engagements have had 0 occurrences over a defined period. Automated suggestion to update or review affected engagements. Reporting enhancement: A view or dashboard that shows which active engagements are referencing URLs that may no longer exist. Value to Users and Admins:Prevents engagements from silently failing. Ensures better targeting accuracy and reduces missed opportunities for user insights. Improves NPS response volume by ensuring surveys trigger where intended. Reduces admin overhead from manually validating URLs. Provides greater confidence and reliability when configuring PX engagements in environments with rapidly changing URLs.Business Impact:This enhancement will directly support teams who rely on PX for critical feedback mechanisms (e.g., NPS, CES, surveys, product onboarding), and it mitigates risks associated with URL‑dependent engagement triggers—particularly for fast‑moving products with dynamic page structures.