Admin QOL: Full Dependency Report

Related products: None

When working in Data Management and attempting to obliterate an improper or vestigial field it would be nice to have a FULL dependency report to help admins locate every spot they need to modify in order to remove the field.

Currently, this only works for one selection at a time and each time you want to investigate where a dependency is, you need to re-input the Field in the top right drop down.

BONUS POINTS: We have an automatic dependency interface/report that allows us to selectively remove a field from multiple areas at once or “Remove all” so the Admin doesn’t have to go to every item (similar to company merge/show all fields). (yes this is very complex)

Give me that Bonus Idea, please!!!

  
End Proctoring-
 

I wish I could vote for this 1000 times.

:heart_eyes:

And this needs to include Data Designer and Journey Orchestrator dependencies!  Currently, the Data Management Dependency mapping does not show these dependencies.

@keith_mattes When user clicks on dependency tab it does give a full dependency report for all fields in an object. Field filter is an added flexibility to view dependencies for a particular field.

@ssamart

The challenge that @keith_mattes is pointing out is that currently you have to select a field per functional area at a time:

  • Search for the field under rules
  • Search again for the field under reports
  • Search again for the field under C360

What we’re all asking for is the ability to search for a field once  and have it display every asset/functional area where the field is being used…

including Data Designer and Journey Orchestrator which it currently does not.

 

I should be able to select a field once and see everywhere it’s being used. Currently this process takes a long time to complete.

@darkknight Thanks for the feedback. We will keep this in consideration in our dependencies UX revamp

Thanks for the assist @darkknight , looks like YOUR coffee was stronger than mine today! :)

I’d like to add that field dependencies should also include their use in Dashboard Global Filters.

 

Basically EVERYWHERE

Success Plans and C360 Summary too.

@dan_ahrens @minh_phan here’s something that really needs to move to the top of the pile.  It’s so easy to inadvertently break things without being able to fully identify dependencies throughout the product.

This bit me hard today because post-NXT migration we had duplicate user lookup paths on our Company object (that no one explained would happen - pre-existing SFDC ID lookups and new GSID lookups)

To reduce confusion and complexity, I’ve been working on trying to swap everything out from the SFDC ID lookup path to the GSID lookup path and was relying on Dependencies (and Analyzer) to help with that effort.

Well, it turns out I missed some places...and so when I deleted one of the SFDC ID lookup paths (which Data Management let me do):

  • The entire C360 Summary stopped displaying (because it was being used as a field on the Summary that I had forgotten) and our users thought Gainsight was down (why would the whole section vanish?)
     

     

  • A Data Designer set freaked out and said ALL fields were removed from a dataset (until I just removed the one Lookup field and saved the set)
  • Success Plans stopped displaying on C360 (just displayed as below - which is astounding..why would the entire Success Plan stop displaying) because it was being used on an SP layout.
  • ALL 16 Dashboard Filters from a dashboard vanished because ONE report was pointing to the old field path in ONE of the Dashboard Filters (also inexplicable - why would they ALL disappear?):
    Broken view
    Fixed view
  • A Journey Program produced an error because it was being used in a query (fortunately only as a show field and nowhere else)

For an enterprise-level application, we really should be able to easily (and trustworthily) identify everywhere fields are being used throughout the product and be prevented from shooting ourselves in the foot.

 

Success Plans and C360 Summary too.

@dan_ahrens @minh_phan here’s something that really needs to move to the top of the pile.  It’s so easy to inadvertently break things without being able to fully identify dependencies throughout the product.

This bit me hard today because post-NXT migration we had duplicate user lookup paths on our Company object (that no one explained would happen - pre-existing SFDC ID lookups and new GSID lookups)

To reduce confusion and complexity, I’ve been working on trying to swap everything out from the SFDC ID lookup path to the GSID lookup path and was relying on Dependencies (and Analyzer) to help with that effort.

Well, it turns out I missed some places...and so when I deleted one of the SFDC ID lookup paths (which Data Management let me do):

  • The entire C360 Summary stopped displaying (because it was being used as a field on the Summary that I had forgotten) and our users thought Gainsight was down (why would the whole section vanish?)
     

     

  • A Data Designer set freaked out and said ALL fields were removed from a dataset (until I just removed the one Lookup field and saved the set)
  • Success Plans stopped displaying on C360 (just displayed as below - which is astounding..why would the entire Success Plan stop displaying) because it was being used on an SP layout.
  • ALL 16 Dashboard Filters from a dashboard vanished because ONE report was pointing to the old field path in ONE of the Dashboard Filters (also inexplicable - why would they ALL disappear?):
    Broken view
    Fixed view
  • A Journey Program produced an error because it was being used in a query (fortunately only as a show field and nowhere else)

We really should be able to easily (and trustworthily) identify everywhere fields are being used throughout the product and be prevented from shooting ourselves in the foot.

 

I feel heartburn just reading this. 

  
End Proctoring-
 

Thanks for sharing this feedback @keith_mattes and @darkknight . Simplification of the admin experience is definitely something that is top of mind for us this year. Samarth (who posted above) is the lead PM on this area of the product, so it’s good that he has eyes on this. :)

This might just be at the top of my list, that is how life-changing this would be.

Adding to this that different views consuming fields that create dependencies should be covered as well - e.g. GS Home custom views, renewal center views, etc.

 

Hi all,

 

Happy to let you all know, with the dependencies UX revamp - all the dependencies for a field will be displayed at one place. This enhancement will be released in Jan’22 RT.

 

Thanks,

Bhawya

 

Hi @Bhawya 

The new Data Management dependency checker still doesn’t seem to include Journey Orchestrator dependencies

Is this going to be included too?

Linking to this post I made earlier as well: 

 

Terms & ConditionsCookie settings