Hiding picklist values from certain users on Create - Answers - Salesforce Trailblazer Community
Trailblazer Community
Ask Search:
Meghan EvansMeghan Evans 

Hiding picklist values from certain users on Create

Hey, Trailblazers!! 

I have a question regarding hiding, or otherwise preventing selection of, a specific picklist value from certain users/profiles, specifically on Create.

For context: 

We have a custom Client Status picklist value on our Accounts object (customized to be Clients) to indicate whether or not we can actively work with them. The idea is, only salespeople and sys admins should be able to edit the Client Status field at all, and then only 4 certain users (VPs of acctg, VPs of sales) can edit the picklist to say Active Client. 

To accomplish this thus far, I have built two validations on the client object, one to allow only certain user types to make changes to the field, it looks like this: 
AND( 
ISCHANGED( Client_Status__c ), 
$UserRole.Name <> "Outside Sales", 
$UserRole.Name <> "VP of Sales", 
$UserRole.Name <> "Sales manager", 
$Profile.Name <> "System Administrator", 
$Profile.Name <> "AdminPlus" 
)

The second validation rule allows only the four specific users to make the status specifically Active Client, and looks like this: 

AND( 
ISCHANGED(Client_Status__c) , 
ISPICKVAL( Client_Status__c,"Active Client"), 
$User.Username <> "(username)", 
$User.Username <> "(username)", 
$User.Username <> "(username)", 
$User.Username <> "(username)" 
)

Obviously in this validation rule, I've subbed in the actual usernames, I didn't think it would be very kind to post their email addresses! 

So the issue I'm running into is this: it works like a charm, except on create. All users of the non-restricted profile types are able to create client records where the picklist value equals Active Client. 

I understand different record types is the surefire way to remove picklist values entirely, but wouldn't be feasible in this case. Any thoughts on how this could be accomplished using another method, or why the validation seems to only work on existing records and not when creating new ones? Other validations I've built are just as effective on create as they are on edit, so it is confusing to me as to why this does not work, unless ISCHANGED() doesn't consider values set upon create to be a 'change', thus not satisfying the ISCHANGED() protocol...
Best Answer chosen by Meghan Evans
Meghan EvansMeghan Evans
Thank you all for your time and responses, it was nice to connect and chat about my quirky issue, definitely helped me digest it better. I chose to implement a PB that runs only on create of client records, that says "if status is anything but Prospective, change it to Prospective." This effectively overrides any selection the user might make upon create and forces it to be Prospective upon initial save. Then, once it's saved, the ISCHANGED() validation takes effect and they cannot change it to be Active after the fact unless they are one of the 4 users not blocked by the validation. Tested it and it works like a charm. Thanks again for helping me work through this!

All Answers

Mike ReynoldsMike Reynolds
It's the ISCHANGED. Think about it like this, there is no "before" to allow the ISCHANGED to evaluate the validation rule. I'd add an OR at the top of your formula so that it's OR( your old rule, AND (users that can, picklist values)
Sarah KhalidSarah Khalid

Hi Meghan,

You can use different record types for restricting picklist values. 

For example:

Your picklist has values A, B, C, D, E, F, G, H
User 1 needs to see only picklist values (A,B,C,D)
User 2 needs to see only picklist values (E,F,G,H)
You would then create (or use existing record types if they are already there in your org). 

If you go into the detail for each record type there is a section called "Picklists Available for Editing", here you would go to the picklist field you need to update and choose which values apply to which record type.

The record types are tied into page layouts and profiles so once you set them up you can define which profiles have access to which record types.
Let me know if that answers your question or if you need any further help.

Mike ReynoldsMike Reynolds
Sarah is totally correct. If you don't need every picklist value on every record, this would create a better user experience. 
Meghan EvansMeghan Evans
Sarah, I appreciate your response but I did mention in my post that the record type solution would not be feasible. Each record can only be one record type, I do not need two records for every client, one which is active and one which is not, I just need my 4 decision makers to be able to make a client record Active and prevent other folks from doing so. 

Mike, I appreciate your feedback on the fact that it is the ISCHANGED which is preventing the validation from acknowledging the change on create of the record, I was afraid that was the issue; however, I'm not sure I understand your suggestion on adding OR, could you please elaborate on that a bit? 
Mike ReynoldsMike Reynolds
I just went to write it out and came up with a better way. Take out the ISCHANGED and just check the two conditions (is the bad value & NOT one of the 4). 

something like this:

AND(
ISPICKVAL( Client_Status__c,"Active Client"), 
NOT(
OR(
$User.Username <> "(username)", 
$User.Username <> "(username)", 
$User.Username <> "(username)", 
$User.Username <> "(username)" 
)))

not saying i wrote that without an error, but that's the idea. 
 
Meghan EvansMeghan Evans
Mike - Ah ok, I see what you're saying, thank you for that. I had actually written it this way originally, and it failed in testing phase because it prevented all users from being able to edit anything about the client once it's become Active unless they were one of those four folks. Sales and recruiting users still need to be able to add notes and fill out other fields on the client record once it's Active. The ISCHANGED does need to be a part of it, so that it locks up only in the event that the field is changed.

Sarah - I'm not seeing your response populate here in the thread but I did get it via email; and that does make sense, but would still run into the same issue as Mike's proposal, if another user wants to add information after it is made Active (and they often do), the validation will prevent them from doing so if they're not one of the 4 defined users because it would satisfy the ISPICKVAL() condition of the OR section. 


I was wondering if maybe a PB could help with this instead, that would run only on create of client records, that would say "if Client Status is not Prospective, make it Prospective", thus overriding any unsavory choices. That way, even though the validation does not prevent them from creating a record that has Active Status value, it will change it upon initial save automatically and they will not be able to change it back because by that time the record will have saved and the ISCHANGED() would take effect.
Mike ReynoldsMike Reynolds
HA! Good point. 

So, crazy idea here, can we create a new field and limit access via FLS? We might be overcooking the goose here with all these validation rules. Creating an IsActiveClient checkbox would be a 1 min solution...
Meghan EvansMeghan Evans
That's fair, but I'm afraid it doesn't really make sense unless I removed the picklist altogether and made 5 checkboxes, one for each available status value (Prospective, Active, Inactive, Credit Hold, and Unqualified), and made just the Active checkbox read-only for all users except the four - and I wouldn't be able to attribute FLS by specific user, it would be by role or profile, and these 4 users each have separate roles and profiles, some of which are the same as other users which should not be able to set to Active. I would also have to go through and edit existing backend processes governed by the Status field to point to these checkboxes instead. It ends up not being a 1-minute solution lol.

I think my best workaround is going to be the PB solution, as far as a combination of effectiveness and least amount of time to execute goes.
Meghan EvansMeghan Evans
Thank you all for your time and responses, it was nice to connect and chat about my quirky issue, definitely helped me digest it better. I chose to implement a PB that runs only on create of client records, that says "if status is anything but Prospective, change it to Prospective." This effectively overrides any selection the user might make upon create and forces it to be Prospective upon initial save. Then, once it's saved, the ISCHANGED() validation takes effect and they cannot change it to be Active after the fact unless they are one of the 4 users not blocked by the validation. Tested it and it works like a charm. Thanks again for helping me work through this!
This was selected as the best answer