Skip to main content

    Idea Pipeline

    Filter by idea status

    Filter by product area

    6162 Ideas

    bradley
    bradleyExpert ⭐️

    Refresh Lookups in Data Designer on Model RefreshNew Idea

    There was much well deserved excitement around this finally being released: However, one very critical, and very key component of this was not only left out, but there was no indication it was left out at all and what the expected behavior should be - the fact the lookups don’t actually *dynamically update*. They refresh at the tenant level every 12 hours.Here is an example:You set up a Data Designer (DD) that has a lookup to the Company MDA, which itself has been turned into an MDA object. You have a rule updating the Status of your Company records After this rule runs, your DD refreshes (within say 1 hour) You run a report on Company>Status and a report on the DD with Company>Status and whatever other fields you need You compare the two “Status fields” between the two objects - they will not match for as much as 12 hours. Any records that were updated by the rule, will not reflect in your DD even if the DD was refreshed right after the rule ran, and it is referencing the Company table via the new lookup method and there is nothing you can do about it*.What does this mean?Refreshing your Data Designs will no longer give you the most up to date data on *any* object you have set up this lookup to. To be clear, if you’re not using the new lookups, the DD work as they always have as far as I can tell.  Testing new data becomes more challenging, because if you need to use a lookup, then you have to wait 12 hours for everything to refresh??? There is (as of this writing) no documentation on this limitation on what the delay is, how it works, when the syncing is, if it can be changed. Nothing. As bad as this lack of refresh is, it’s made worse by the fact it was not communicated in any way. What is the ask?First and foremost - lookups should refresh on a per DD basis. If a data design refreshes, the expectation is that the data in there is accurate *at runtime*. Secondly - this needs to be documented, and *proactively* communicated to admins. Even just the current state. Adding the documentation is one thing, but making sure there is proactive outreach to admins is critical. In the short term, at the very least, reduce the time for this syncing This is a glaring problem that undermines the one of the main utilities of this being released in the first place, and the fact that it is not documented anywhere is extremely disappointing to say the least. *support has indicated it might be possible to reduce this time on a per tenant basis.

    JayS
    JaySHelper ⭐️

    Add the ability to select a snoozed option when setting audience rulesNew Idea

    I’ve been thinking about scheduling PX engagements and the snooze option. I don’t use it often because it counts as a view, so it doesn’t change the schedule. So, when a user gets their last view in the schedule and they click snooze, they are expecting to see that engagement again, but with the current functionality, they won’t see it again.A couple potential solutions:Make the click on snooze not count as one of the views. For example, if the schedule is set to show the engagement 3 times with at least 7 days between views: Upon first view, user just closes engagement; that counts as their first view and they have 2 left. Upon second view, user clicks snooze. This should not count as a view and they should still have 2 left If user continues to click snooze on their third view, they should qualify to see it again in 7 days; potentially indefinitely if they keep clicking snooze. Add a SNOOZED option to the In App Engagement audience rule. This would give us the opportunity to target users for a “last chance” at the engagement. If the user has previously only VIEWED or COMPLETED the engagement, they wouldn’t qualify to see the last chance engagement. My assumption here is that if a user is clicking snooze, they want to see the engagement again and just may not have time to review it at that moment. (That is my thought when I’m presented with a snooze option.) Add SNOOZED option to the Event category  I’m referencing this article:  cc: @Lake1211 @Gainsight2022 @woodlande @wheelern @rterakedis @aroberts @jmobley @aharkut 

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

    Distinguish Automated API Updates from Manual User Actions in TimelineNew Idea

    Currently, when a Timeline activity is updated via the API, the “Modified By” field is attributed to the user who last authorized the External Connection or updated the API key: Timeline UI This creates significant friction for our team and end users:Auditing & Compliance: It is currently impossible to distinguish between a manual intervention by an Admin and an automated system update. For auditing purposes, these should be distinct. User Confusion: When automated updates are stamped with a human name, it creates the illusion of manual intervention, causing confusion for end users and forcing the Ops team to waste time explaining system behavior.Context & Impact: In our specific use case, these Timeline activities contain highly sensitive information and we use an External Action to toggle a boolean to True once a dependent process completes.Despite this being a minor, binary background update, the system stamps a human name on the record. This makes a routine automated handshake look like a manual manual override of sensitive data, which is misleading and complicates our debugging and oversight processes. Requested Change: Please ensure system consistency by attributing these automated changes to "System Administrator" rather than the individual user who happens to hold the connection credentials. This would align the Timeline behavior with other automated system logs and provide the clarity required for sensitive data management. 

    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