Skip to main content

    Idea Pipeline

    Filter by idea status

    Filter by product area

    6164 Ideas

    bradley
    bradleyExpert ⭐️

    Please Have Documentation Match Product FunctionalityNew Idea

    This is specifically about the new rollout of the Cockpit and Task Real Time Rule action, but really this should be treated more as an example than a request to just fix one thing, hence the generic title. The fact that Real Time Rules doesn’t support Custom Events is a pretty important detail that should have made it directly into the release notes. Custom events are supported on other action types so there wouldn’t be a reason to think they would not be supported and should be called out here: If you follow the link to Events in Real-Time Rules you scroll down and see this: No particular call out that Custom isn’t supported, it’s just not listed. It really should be explicitly mentioned it is not supported. In my instance however, I have the option for custom: Maybe they forgot to add it to the docs as a supported action? After all, the fact that it’s being rolled out incrementally was added later.It’s not called out anywhere but it’s here on my list. No indication at this point it wouldn’t work. Until you try and add a field, then you see this:  I’ve already made a post here about it and I hope it’s already on the roadmap, but clarity in documentation is super important and I’m just not seeing that. There’s also discrepancies around the actual functionality of some fields in an object which isn’t a great place to be either. An enterprise level platform needs accurate, reliable, and trustworthy documentation. With a quarterly release, time and resources need to be baked in to make sure that that happens.

    bradley
    bradleyExpert ⭐️

    Data Validation on LookupsNew Idea

    The ability for users to edit fields, especially en masse, has been expanding. Instead of just being limited to fields in areas like CTAs, Success Plan, etc., fields can also be edited on Mass Edit Scorecard reports, some 360 attribute areas, and more recently My Portfolio and even in-line editing.While these can make both admin and user lives easier, they unfortunately lack some pretty standard capabilities across areas of the product to make using it viable. There are so many admin restrictions and caveats, and so little ability for us to put guardrails consistently these benefits are sometimes rendered completely unusable.One main area is any kind of data validation when making lookup fields editable. There are a few places where this is possible, but even those are not done particularly well (see this post). However, we should be able to put the same filter validations anywhere we make a lookup editable (there may be some exceptions for certain system things). Example:If you add a lookup field to a CTA where you allow the user to edit it, you have the ability to set up filters to limit the results. This is super helpful if you want to make sure a user can only add a record related to that company:  If you have a lookup on the Company object, there does not appear to be any way to add this kind of filter either at the field level, or in the report setup when you want to allow in line editing to change what record the lookup is associated to. What this means, is that if you have say, a look up to the CTA object and you want to associate a particular CTA via that lookup, you cannot restrict the search to CTAs just for that company or relationship. You get every CTA under the sun. You might even be limited in the search fields you can display, to even show what company the record is associated with in the first place.This just makes an overall poor and inconsistent experience for both admins and users.Please allow us to set up filter/validation restrictions on lookups throughout the platform, if we are asking for user input.

    awellsContributor ⭐️⭐️

    Fix User Management in PXNew Idea

    I don’t know how else to put this so allow me to be blunt, and I will apologize up front for seeming overly passionate here. User management in PX doesn’t work. Unlike in Gainsight CS, user fields are locked. You cannot modify the user’s name or email without, as support informed me, creating a new user account and transferring ownership to the new account. This is beyond frustrating considering names and emails change all the time. You get married and want to have your new name reflected in PX? New account! Someone misspelled your email address and need it fixed? New account! You went through an email migration and now have a different domain in your email address? You guessed it, new account! Oh and it gets better. A new account means you have to go through the account activation flow all over again. So that means another welcome email sent to your users and another password being created that may or may not be used. And don’t forget after the user activates a new account you cant just get rid of the old one you have to transfer ownership of reports and dashboards, otherwise that user has to redo all their work. Rather than doing all that wouldn’t it be easier if we could just, you know, be able to edit the fields?Okay now that my rant is over here is what I would like to suggest:Establish a unique identifier that is not the email address. ← From my conversations with support that I am lead to believe email address is what you are using as the unique identifier. Allow admins to edit the email, first name, and last name fields. ← Again names and emails change all the time for various reasons. Allow admins to decide if a welcome email should be sent out. ← If you are using an IDP then you may not want these to go out. From the user management page allow admins to reset a password and/or require password reset on next sign in. ← For those who allow users to log in via password On the topic of passwords allow the admin to set a password policy. Being able to bulk create users would also be nice or better yet allow for just in time provisioning from the IDP.I’ll stop here this is already borderline a novel. Bottom line please fix user management in PX. Creating a new account for everything is not sustainable, causes unneeded confusion with the users, and makes managing users painful.  

    darkknight
    darkknightExpert ⭐️

    Change "Once in X Days" and "Include in identifiers" interdependency for auto-generated CTAsNew Idea

    I could have sworn there was a post about this sometime in the past, but here goes:The use of the "Create CTA Once in X days" functionality when combined with the "Include in Identifiers" option creates a problem that has existed for a long time but still has no solution.If a CSM edits the name of a CTA, it resets the “once in X Days” restriction that’s supposed to prevent duplicate CTAs. This means that after the name change, the system no longer treats the CTA as an existing one and will trigger a new CTA before the X-day window expires. This causes duplicate CTAs for the same task, cluttering workflows and creating confusion.The only thing I can do as an admin is say “Please don’t change the name of the CTA, ok?” which is routinely ignored bc users either don’t pay attention to enablement half the time or go rogue. Why this is problematic:Duplicate CTAs: Name changes bypass the X-day restriction, so you can end up with multiple CTAs for the same issue, adding unnecessary clutter. Inaccurate Reporting: Multiple CTAs skew reports and tracking, leading to data inconsistencies. Wasted Time: Admins or CSMs have to manually clean up these duplicates, defeating the purpose of automated workflows.  Isn’t there a backend value that correlates a triggered CTA to a specific action that can be used in the “X-days” evaluation instead of the CTA Name?Or, at a minimum, give us an option in a rule action to “lock” the CTA Name from being edited for CTAs that are auto-triggered.