Skip to main content

    Idea Pipeline

    Filter by idea status

    Filter by product area

    6164 Ideas

    achamariaGainsight Employee ⭐️

    Hierarchical ARR RollupNew Idea

    Use Case: They aimed to aggregate the Annual Recurring Revenue (ARR) for each level by summarizing the figures from subordinate companies up to their parent companies, continuing this process through consecutive levels until reaching the top parent. Solution: Automating the aggregation of Annual Recurring Revenue (ARR) across four hierarchical levels is not feasible with a single rule/data designer. This is because each level must be aggregated sequentially, starting from the lowest, to accurately calculate the totals for the parent company along with its subordinate entities.A rule chain had to be created consisting of 3 independent rules to achieve the ARR Rollup.  Rule 1:Step1: We are fetching the data where the Companies do not have a parent company by using the filter Parent Company GSID is Null.  Step 2: Again, fetching the data where the Companies have a parent company by using the filter Parent Company GSID is not Null.  Step 3: Merging the above data sets to get the 1st set of Parent-Child Companies. Step 4: Merging the data from the merge (Step 3) to the company data from Step 2 to get 2nd set of Parent-Child Companies. Step 5: Merging the data from the merge (Step 4) to the company data from Step 2 to get 2nd set of Parent-Child Companies. Step 6: Transforming the data of the above merge (Step 5) to get the aggregate ARR of the child companies. Step 7: Creating an action on the transform (Step 5) to load the aggregated ARR to the Company ARR. Rule 2:Step1: We are fetching the data where the Companies do not have a parent company by using the filter Parent Company GSID is Null.  Step 2: Again, fetching the data where the Companies have a parent company by using the filter Parent Company GSID is not Null.  Step 3: Merging the above data sets to get the 1st set of Parent-Child Companies. Step 4: Merging the data from the merge (Step 3) to the company data from Step 2 to get 2nd set of Parent-Child Companies. Step 5: Transforming the data of the above merge (Step 4) to get the aggregate ARR of the child companies. Step 6: Creating an action on the transform (Step 5) to load the aggregated ARR to the Company ARR.Rule 3:Step1: We are fetching the data where the Companies do not have a parent company by using the filter Parent Company GSID is Null.  Step 2: Again, fetching the data where the Companies have a parent company by using the filter Parent Company GSID is not Null.  Step 3: Merging the above data sets to get the 1st set of Parent-Child Companies. Step 4: Transforming the data of the above merge (Step 3) to get the aggregate ARR of the child companies. Step 5: Creating an action on the transform (Step 4) to load the aggregated ARR to the Company ARR.  To accurately populate the aggregated ARR for each respective parent company, all the above-mentioned rules must be executed in the proper sequence. Conclusion : The implementation of the ARR roll-up hierarchy has established a structured method for accurately aggregating Annual Recurring Revenue at multiple hierarchical levels. By ensuring that each level is aggregated sequentially, starting from the lowest tier, we maintain precision and integrity in our financial summaries. This organized approach allows parent companies to have a comprehensive view of total revenue, reflecting the contributions from all subordinate companies. The sequential execution of rules is pivotal for this system, and adherence to this process ensures that revenue data is consistently accurate and reliable. Ultimately, this refined hierarchy facilitates enhanced financial oversight and robust strategic decision-making. 

    bradley
    bradleyExpert ⭐️

    Email from Anywhere (Beta) Organization-Wide EmailsNew Idea

    At time of writing this feature is still in Beta, but I wanted to surface a couple of key things that with the feature ‘as-is’ make it less compelling to adopt: Organization-Wide Email Permission Management:Currently, the owner of the email you want to use org-wide gets an email for each request to give one or more users the ability to use that email. You have to add each email manually (no groups or lookups, you have to hand type each one) to a request for each email address you want a user to have access to. So, if you add 500 users to a single request then one email goes out to the approver. If you do them one at a time they get 500 emails. If you have 2 email addresses you’d like users to have access to org-wide that would be up to 1000 approval emails sent. There doesn’t appear to be a way to report or mass edit who has access to which email either, so you have to manually verify and add/delete them as well.This is already quite tedious - even if you initially add all your current users to one request, you will still have to add every new user manually going forward. Do you do them one at a time? In batches? What if an existing user changes their email address? There are likely some constraints around getting permission from the email owner, but the method as currently implemented is not scalable. If the idea is to help enable Admins to develop better pooled CSM models, managing this is going to be a huge pain point as is. Please find a way to leverage user groups, permission sets, rules, anything that can be managed at scale to organize and track the requests. The permission requests should ALSO tied to users NOT just an email address in a way that is exposed to admins.There should also be a way to report on which user (not just which email address) has access to which org-wide email.

    link_black
    link_blackGainsight Employee ⭐️⭐️

    PX Product Environments should maintain entirely separate User/Account records and should not share dataCurrent Behaviour

    Submitting this on behalf of a customer… Background:Having different sets of account/users within each PX Product Environment is normal and supported by PX.  However, PX adheres to Unique ID principles and there can be one and only one User/Account per unique identifier across all PX Products and PX Product Environments.  Challenge:If Users/Accounts share the same unique identifiers in different PX Product Environments and are passing different User/Account attributes (e.g. names, email addresses, custom attributes, etc.) then any changes are updated across all Users/Accounts within that PX Product in every PX Product Environment. Additionally, any tracked usage in ALL Environments is also visible on the User Profile → Recent Activity section and is not correct. Request:Allow PX to support this model so we do not need to worry about matches to unique identifiers in other PX Environments altering data in a different PX Environment. Most companies I’ve worked for have completely unique sets of users and accounts per environment without any guarantee of uniqueness from environment to environment.  I would imagine other Gainsight customers would like this support as well. Current Solution:Do not share User/Account Ids across PX Product Environments.  One way to avoid this is to prefix each PX Environments non-production IDs with something unique (e.g. P{ID} for prod, Q{ID} for qa, etc.)  so that these kind of overwrites and unexpected updates will not happen. The other option is to use separate PX Subscriptions, but using PX Product Environments is recommended as a best practice.