function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
kevindotcarkevindotcar 

Can I Turn VR off for certain profiles and certain fields?

I have a VR that does not allow certain users to edit a closed opporunity (and some can, like Operations and Admins).  
That part works fine and is very simple.

But, I have a a use case where if an Opportunity is closed, I want users with one profile to be able to modify just certain fields on the opportunity.

Is this possible?  
We  have about 150 fields on the Opportunity object, and I obviously can't go off making a VR for each one.
We have been working with a few ideas;  One is  putting all of these fields off onto a separate object and displaying them on the Opportunity with an inline VF page, but that requires two save buttons (one for the custom object and one for the opportunity).  Another is using a different record type and making all fields except the writeable fields read-only, but that's a lot of maintenance also.

Does anyone have any other ideas? Thanks in advance for any advice.
 
venkat-Dvenkat-D

I think easy way should be 
Chcek for

NOT NEW
Status = xyz
profile != xyz

and throw error. You can throw error if its just not new which means edit.
Parker EdelmannParker Edelmann
This may work, but it's not too pleasant to write though, but better than 150 VRs.
 $Profile.Name = "The Profile Name" &&   IsClosed && OR( ISCHANGED(field1), ISCHANGED(field2), /* repeat for all the various fields */) 
I wish I had a better solution than this, but I hope this will help though,

Thanks for reading,
Parker
Tolga SunarTolga Sunar
Another option could be creating multiple page layouts, and then assigning these layouts to profiles (no need for record types here). In layout, make the fields you don't want users to edit read-only. You will not be able to make universally required standard fields (Name, CloseDate and Stage) read-only, thus you'll create validation rules for these in order to make render them uneditable. This approach seems to fit best for your needs.
Parker EdelmannParker Edelmann
@Tolga Sunar, wouldn't that mean though that when the opportunity is open, and you do want them to be able to edit certain fields, they wouldn't be able to? The only gap in the current solution is one profile still needs to edit certain fields past close. Mind explaining how that would work?
Tolga SunarTolga Sunar
Ah , missed role of opportunity stage here... Then yes, you're right, two record types for open opportunities and closed opportunities are needed, along with a workflow or process that switches the record type (hence the layout) based on opportunity stage. This is exactly what's stated in the second method in the question, I guess.

First method does not make sense at all. Requirement can be met by just long validation rules as stated here, but I wouldn't go for that because at the first glance I wouldn't know which fields I have the right to edit in a closed opportunity.
Parker EdelmannParker Edelmann
That can be solved with a quick email, or a chatter post. Also, for the validation rule error, just say that only profile A, B, and C can edit it and C can only edit fields X, Y, and Z after close.
kevindotcarkevindotcar
@Tolga   The first method (putting all of these fields off onto a separate object and displaying them on the Opportunity with an inline VF page) has the advantage of having a controller extension for the "Special Fields" object that can throw an error if the profile isn't allowed.

Another (but related) idea  - instead of putting the page inline on the Opportunity, I COULD just have a custom button on the Opportunity that says "Edit Special Fields" (or some such) and it goes to a separate page.   Also, if I go to this route, the edit page (a VF pge) could be overridden with my own "Save" button that checks the profile of the user and displays an Apex.Message error ---

But, it sounds like a new record type is the community's answer...