Refresh Dependencies Each Visit

I 100% support this. The loading time saved by caching previous dependency check results is NOT worth the risk introduced by displaying out of date dependencies.

Just to add another example, here’s one I came across today:

More than six months ago!!

But wait, there’s more!

First time looking at this objects dependencies, why was it last refreshed a year ago?

@revathimenon can we get some 👀 on this?

On it @bradley 

Hello,

Thank you for your feedback. We understand your concern regarding the freshness of the dependency data. Here’s our rationale and the current approach:

We deliberately chose to cache field dependencies to enhance performance by providing faster access. Field dependencies change infrequently, so caching them minimizes load times and improves usability.

When you load dependencies in Data Management, it shows the results from the last time you ran it for that object. This is why you might see different fetch times for various fields. The "Updated On" date indicates the last time the data was refreshed.

To ensure you always have the most up-to-date information, we display the last refresh date and time upfront. If you need the latest dependencies, you can get this with just one click of refresh button.

We believe this approach strikes a balance between performance and data freshness, providing a quick and easy way to refresh dependencies when needed.  

As we focus our efforts on other high priority items, unfortunately we would not be picking up this anytime soon but we will keep an open mind to revisit this at an appropriate time 

@Prateek Parashar Appreciate the insight, and understand that it is not a particularly high priority, but in the event it is considered a “low hanging fruit” and something like this can get squeezed into a release (see what I did there? :) ) I have to fundamentally disagree with your two main points of reasoning:

• “Field dependencies change infrequently”. My friend, I must strongly disabuse you of this idea. Field dependencies change ALL THE TIME. Make a new report? New dependency. Add a new field and use it literally anywhere (why else would you make a field?). New dependency. New rule? Heaps of new dependencies. New Data Design? So many dependencies. 
• “Caching them minimizes load times and improves usability”. I cannot think of a single time where I have gone into dependency management, seen the last refresh date anything other than today and been “gee, why bother hitting that refresh button?” The only reason I’m there is because I need to know the current dependencies. 
  • The only load time I would care about having minimized, would be if for some reason having this load every time I went in there slowed down the entire rest of the platform which I don’t think is the case.

Maybe instead of refreshing every single time, a better compromise would be to have it refresh automatically only if the last time it was refreshed was more than 24 hours ago. If you want it accurate to the minute, then users can do it manually.

As it is, I seriously need you to re-evaluate the use case for this if you really believe that year old data is “a good balance” for anyone using this tool. Again, you are correct in that it is not a high priority, but this reasoning shows a fundamental disconnect between how Gainsight thinks people need features to work and how we actually need to be able to use them. 

@pgeorge Maybe I’m coming in a bit hot here but this strikes me as a small example of of the design and user disconnect many of us here bring up all the time.

@bradley  Thanks for your detailed comments and highlighting the frequency change of field dependencies. Appreciate it. We will will keep this point in mind while brainstorming solutions to this ask.

One of the reason behind taking approach was also to reduces the strain on resources and the number of API calls required, as this operation involves multiple micro services across the platform.In summary, its about managing a resource-intensive operation (fetching dependencies from multiple micro services) by reducing its frequency, while still allowing for scenarios where fresh data is necessary.

Users can still manually refresh dependencies when needed ( an additional one click and wait time of few seconds), and fresh data is fetched during critical operations like field deletion( whenever a field is deleted ,we automatically refresh).

One of the proposed solution( again, we have not thought in details about ALL possible solutions) is we can refresh every Saturday/Sunday for the main standard objects. As you already mentioned, unfortunately this is not a high priority item for us, considering all the other things that we intend to work upon, but we will keep this in our long-term roadmap.