Can you 'hide' a value from a dropdown that uses a linking picklist?

[Anonymous]

Hello,

I have an scenario where we have a dropdown that should only display 5 options to all users, but it should display 6 options to members of the SCM team. The picklist uses values from another workspace, and I was trying to see if using 'Additional Owners' and permissions would allow me to control who sees 5 vs 6 records, but I cannot make it work. 

Is this possible or is there another way to do it?

Thanks!

[tony.mandatori]

How about adding a filter that removes the extra record?

[Anonymous]

Hi @tony.mandatori; I need it to appear for a certain group of users but not for others. Could this be achieved using filters? Do you mean adding them in the source linking workspace?

[tony.mandatori]

I misunderstood.  I don't think the filter will work if users should see different records.

To control which picklist items that users can see, I would revoke the permission for users to see records owned by others, and then add users as owners of the records they should see in the Workspace that defines the picklist.

Would that work?

[Anonymous]

@tony.mandatori can't figure out a setup that works for that (maybe I am doing something wrong). However, there are other items to consider:

1. The linking picklist is from a WS to which only 3 people have access

2. The linking picklist is in a WS to which all users have access, and they can see all the values in the dropdown

Since #2 is true, it means that there are no restrictions in picklists being displayed. All users can see values coming from a workspace to which they don'e have permission to access directly. Thus, how could limiting via 'view records owned by others' affect this picklist?

Thanks!

[tony.mandatori]

I would change the workspace that defines the picklist values.  Here's what I'm thinking:

1. Create a new Role for the users that should only see a subset of items in the Picklist: Restricted Role
2. Create a new Role for the users that should see all the items in the Picklist: Unrestricted Role
3. Add the appropriate Groups each Role.
4. Remove groups from the existing Roles
5. Add "View Items to both Roles"
6. Add "View Records Owned by Others" to the Unrestricted Role
7. Add the Groups as Additional Owners to the items that should be viewed by both Roles.

When users display the picklist, they will only see records they have access to... and the Restricted Role will have access to only some of the records.  While the Unrestricted Role will have access to all records.

[Anonymous]

Hi @tony.mandatori, I may be doing something wrong in the setup. Cannot get that to work. I still see all the values in the dropdown, even though, in the workspace itself, the restrictions are working fine. Could you please provide an example of your setup? Thanks!

[tony.mandatori]

Wendy, 

I see the same thing you do:

Although the user does not have access to see the record in the Picklist Workspace, he CAN see the record if it is included in a drop down in both classic and modern.

I think this is a security issue and I will ask PD about this.

Thanks!

[Anonymous]

Thanks @tony.mandatori! Please let me know if I need to report as a bug or it will be escalated from here. Thanks!

[tony.mandatori · Accepted solution]

I think it's a good idea to report it.

[Anonymous]

Thanks @tony.mandatori, I have reported (#14973895).

[tony.mandatori]

Wendy,

I talked to Product Development and I think we can get it to work if we use a Field that isn't the descriptor for the picklist values - I'll try this out and post on this thread again.

Thanks,

[tony.mandatori]

I wasn't able to get this to work either.

[Anonymous]

Thanks @tony.mandatori Please keep me posted support said they would be following up based on this thread

[Anonymous]

@tony.mandatori i was just thinking of a scenario we should consider if this is to be fixed. We have multiple supporting workspaces that are just used to manage picklists, but users don't really need to access them directly. I am not sure if the security feature is addressed, if this means that we have grant access to users now to at least READ all of these other supporting workspaces (ideally not, but something to consider). Thanks!