Remove Company Lookup on User object

Related products: None

Could we please have the option to remove the Company Lookup on the User object. Our Users (i.e. SF licence holders - we use the connector to bring them in) are not related to a company in Gainsight, but when using reports any of the user related fields such as Created By, Modified By, Owner all have lookups to Company so if I search for a company field they also all come up, this is quite confusing and is a blocker to me opening up access to reporting to additional persons in the business (that are not aware of object structure etc) as they can easily pick the wrong field and get no results. 

TBF this probably goes for other system/standard objets and fields - we should at least be able to choose to hide them in reporting (e.g. if we’re not loading anything to them). 

@HollySimmons Sorry for the delay here! I will work with product team as well as look for any alternate and get back to you. Thanks!


Hi @HollySimmons,

Let me know, if my understanding is correct. Because of standard and System lookups created, is it difficult for you to choose the right fields especially when the Custom lookups to same objects are defined?

If the above is true, we have some plans in the roadmap for the capability to edit certain attributes for our Standard and System fields. We will also check if we can also include the ‘hide in reporting’ attribute as well.

Thanks


Hi @soumitrasahu , yes because there is a lookup to company from the user object; 
 

 

then in reports I can end up picking a field from the company associated to a user, but these will always be blank as we don’t associate our users (which are our internal staff) to companies. 

 

 

thanks


Hi @HollySimmons ,

Thanks for the explanation. We have got the idea you have mentioned here. The post has been moved to ‘Under Consideration’.


@HollySimmons  - With end user reporting you can remove access to company as an object for the SF licence holder group, in essence they would then only see User Object and not the lookup 

but the side effect would be they ( SF license holder group ) cannot report on company as a standalone object. ( is that acceptable ) 


@HollySimmons  - With end user reporting you can remove access to company as an object for the SF licence holder group, in essence they would then only see User Object and not the lookup 

but the side effect would be they ( SF license holder group ) cannot report on company as a standalone object. ( is that acceptable ) 

@Azad not sure an all-or-nothing approach is going to be a very attractive proposition. If I have a report type I want users to have access to, but not have access to a lookup for whatever reason but the cost is that said users will no longer have the ability to report on that object anymore seems a bit too scorched earth for me and really takes away the utility of end-user reporting.

 

FYI @darkknight and @zach_davis 


@HollySimmons  - With end user reporting you can remove access to company as an object for the SF licence holder group, in essence they would then only see User Object and not the lookup 

but the side effect would be they ( SF license holder group ) cannot report on company as a standalone object. ( is that acceptable ) 

@Azad not sure an all-or-nothing approach is going to be a very attractive proposition. If I have a report type I want users to have access to, but not have access to a lookup for whatever reason but the cost is that said users will no longer have the ability to report on that object anymore seems a bit too scorched earth for me and really takes away the utility of end-user reporting.

 

FYI @darkknight and @zach_davis 

I agree with @bradley here. Couldn’t this be handled with field level permissions?


@HollySimmons  - With end user reporting you can remove access to company as an object for the SF licence holder group, in essence they would then only see User Object and not the lookup 

but the side effect would be they ( SF license holder group ) cannot report on company as a standalone object. ( is that acceptable ) 

@Azad not sure an all-or-nothing approach is going to be a very attractive proposition. If I have a report type I want users to have access to, but not have access to a lookup for whatever reason but the cost is that said users will no longer have the ability to report on that object anymore seems a bit too scorched earth for me and really takes away the utility of end-user reporting.

 

FYI @darkknight and @zach_davis 

I agree with @bradley here. Couldn’t this be handled with field level permissions?


@zach_davis This isnt about permissions since you want to user to have Access to both but the view he is presented is different. 

Question @bradley  - Wouldn't it become to granular to manage 
For each object +  group, which lookups they have access too. 

 @HollySimmons  - question would the remove lookup be applicable across the org or only for a specific group of users. 


n
Question @bradley  - Wouldn't it become to granular to manage 
For each object +  group, which lookups they have access too. 

 ​​​​​

Hey @Azad great question, thanks for asking. To some extent you are correct, however, I would posit that isn’t inherently a bad thing. 

 

  • For one thing, I think the method by which additional flexibility is implemented will have a big impact on how cumbersome it is to administer.
  • To clarify, I would add that complexity != difficulty in all cases. While this can often be true, in my experience a good complex design can actually be easier (and better) to use than a ‘less complex’ poorly designed experience.
  • The other thing I would add, is that if permissions and configuration tools are sacrificing in robustness for the sake of ‘ease of use’ to the extent that the feature cannot meet our business needs, then we cannot use said feature and the whole conversation becomes a moot point.

Is there a way this could be designed so that admins can configure reports with as much, or little, granularity that they need? I think flexibility in complexity level would serve more orgs better, than trying to design to the lowest common denominator.