function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
Petercass88Petercass88 

validation rule modifying a custom field

I would like to take a custom check box field "requirements spec sheet reviewed by engineer" only modifyable by certain users.  I cannot seem to find any literature on creating a validation rule where i can list out specified users that should have access to modifying that field and the salesforce general examples dont even pass a syntax check.

 

My goal for this is that i dont want the field to be able to be selected by any user as it is a gatekeeper field.  I only want administrators and engineers able to check off this box. 

 

Is this possible the way i am looking to do it?

 

Thanks!

Best Answer chosen by Admin (Salesforce Developers) 
Petercass88Petercass88

Thanks for the help!  That worked like a charm.  For those of you that may be looking to do the same thing (make a field restricted to certain users by last name) here is what i modified to code to read:

AND(
ISCHANGED(  Requirements_Spec_Sheet_Reviewed_by_Eng__c  ),
NOT(OR( $User.LastName   = "Hartman" , $User.LastName   = "Cassidy" , $User.LastName   = "Hill" , $User.LastName   = "Beck" , $User.LastName   = "Bradley" , $User.LastName   = "Butler" , $User.LastName   = "Team")))

 

All Answers

Steve :-/Steve :-/

You could write a VR that only allows certian User ID's to edit the field, but you're much better off using the Field Accessability Settings and Field Level Security for this 

 

About Field Accessibility

 

Available in: Enterprise, Unlimited, and Developer Editions
User Permissions Needed
To view field accessibility:“View Setup and Configuration”
To change field accessibility:“Customize Application”

AND

“Manage Users”

Several factors help control whether users can view and edit specific fields in Salesforce.

  • Page layouts—You can set whether fields are visible, required, editable, or read only.
  • Field-level security—You can further restrict users’ access to fields by setting whether those fields are visible, editable, or read only. These settings override any field properties set in the page layout if the field-level security setting is more restrictive.Important
    Field-level security doesn't prevent searching on the values in a field. To set up your organization to prevent users from searching and retrieving records that match a value in a field hidden by field-level security, contact salesforce.com Customer Support.
  • Permissions on profilesSome user permissions on profiles override both page layouts and field-level security settings. For example, users with the “Edit Read Only Fields” permission can always edit read-only fields regardless of any other settings. Note that the field accessibility grid includes any field access restrictions based on permissions.
  • Universally required fields—A custom field can be made universally required, which overrides any less-restrictive settings on page layouts or field-level security.

After setting these items, you can confirm users’ access to specific fields using the field accessibility grid.

 

 

Setting Field-Level Security

 

Available in: Enterprise, Unlimited, and Developer Editions
User Permissions Needed
To set field-level security:“Customize Application”

You can define which fields users can access. Field-level security settings let administrators restrict users’ access to view and edit specific fields in the following places:
  • Detail and edit pages
  • Related lists
  • List views
  • Reports
  • Connect Offline
  • Email and mail merge templates
  • Custom links
  • The partner portal
  • The Salesforce Customer Portal
  • Synchronized data
  • Imported personal data

The fields that users see on detail and edit pages are a combination of page layouts and field-level security settings. The most restrictive field access settings of the two always apply. For example, if a field is required in the page layout and read only in the field-level security settings, the field-level security overrides the page layout and the field will be read only for the user.

Important
Field-level security doesn't prevent searching on the values in a field. To set up your organization to prevent users from searching and retrieving records that match a value in a field hidden by field-level security, contact salesforce.com Customer Support.

You can define field-level security for multiple fields on a single profile or for a single field on all profiles.

Setting Access for Fields on a Single Profle

  1. Select Your Name | Setup | Manage Users | Profiles.
  2. Select a profile.
  3. In the Field-Level Security section, click View next to the tab you want to modify, and then click Edit.
  4. Specify the field's access level.

 

Access LevelEnabled Settings
Users can view and edit the field.Visible
Users can view but not edit the field.Visible and Read-Only
Users can't view or edit the field.None

  1. Note
    When changing field settings for accounts, opportunities, cases, contacts, or custom objects, check for any criteria-based sharing rules that use the field in the rules. For example, if you hide a field that's used in a criteria-based sharing rule, any users who could access certain records because of the sharing rule will no longer have access to those records.
  2. Click Save.
After setting field-level security for users based on their profiles, you can:
Note
Roll-up summary and formula fields are always read only on detail pages and not available on edit pages. They may also be visible to users even though they reference fields that your users cannot see. Universally required fields always display on edit pages regardless of field-level security.

The relationship group wizard allows you to create and edit relationship groups regardless of field-level security. For more information on the behaviors of relationship group members, see Relationship Group Considerations.

Setting Access for a Single Field on All Profiles

  1. Select Your Name | Setup | Customize, click a tab or activity link, and click Fields.
  2. Select the field you want to modify.
  3. Click Set Field-Level Security.
  4. Specify the field's access level.

 

Access LevelEnabled Settings
Users can view and edit the field.Visible
Users can view but not edit the field.Visible and Read-Only
Users can't view or edit the field.None

  1. Note
    When changing field settings for accounts, opportunities, cases, contacts, or custom objects, check for any criteria-based sharing rules that use the field in the rules. For example, if you hide a field that's used in a criteria-based sharing rule, any users who could access certain records because of the sharing rule will no longer have access to those records.
  2. Click Save.

 

Petercass88Petercass88

The reason i am seeking out using a validation rule is because we are only running professional edition, field level security doesnt really start hitting home until enterprise edition.

Steve :-/Steve :-/

Ugh!  I wish you had mentioned that you were on PE up front that would have saved a bit of trouble.

Petercass88Petercass88

my apologies

Steve :-/Steve :-/

Okay here's a VR you can borrow and hack.  This one prevents anyone except Admins from changing the Account.Name. 

 

AND(
ISCHANGED( Name ),
NOT($Profile.Name = "System Administrator"))

 

 

Petercass88Petercass88

Thanks for the help!  That worked like a charm.  For those of you that may be looking to do the same thing (make a field restricted to certain users by last name) here is what i modified to code to read:

AND(
ISCHANGED(  Requirements_Spec_Sheet_Reviewed_by_Eng__c  ),
NOT(OR( $User.LastName   = "Hartman" , $User.LastName   = "Cassidy" , $User.LastName   = "Hill" , $User.LastName   = "Beck" , $User.LastName   = "Bradley" , $User.LastName   = "Butler" , $User.LastName   = "Team")))

 

This was selected as the best answer
Steve :-/Steve :-/

A word of advice, I would avoid using $User.LastName like you are in your VR.  You might be better off creating a custom field on the user object (like a checkbox or picklist) that indicates that they can edit that field.  And then refer to that in your VR

 

AND(
ISCHANGED(Requirements_Spec_Sheet_Reviewed_by_Eng__c),
NOT($User.Spec_Sheet_Editor__c = TRUE))

 

 

Petercass88Petercass88

this is a very good point... thanks again for the help! I will go adjust, that will make things easier going forward!

Petercass88Petercass88

the formula now reads:

AND(
ISCHANGED(  Requirements_Spec_Sheet_Reviewed_by_Eng__c  ),
NOT( $User.Can_Approve_Spec_Sheet__c = TRUE ))

 

and the field was inserted as a check box at the user level.  Thanks for the advice!  works perfectly

Steve :-/Steve :-/

No problem, you owe me a beer!

Petercass88Petercass88

I will ship one in the mail, it might get warm and shook up a bit though! Caution upon opening... ha!

Petercass88Petercass88

You live in the boston area? I will be there in 5 days, I can hand deliver :-) haha!

gramch88gramch88

I am trying to write this validation rule that allows account managers and system administrators to edit a checkbox field. This is what I have so far. The checkbox field is called "extsys_kb_access__c". The rule is still restricting system admins to edit, but allowing account managers to edit.

 

Here is the rule, let me know if you can help!

AND( 
ISCHANGED(extsys_kb_access__c ), 
NOT($UserRole.Name = "AirWatch Account Mgr"), ($Profile.Name = "System Administrator"))

 

 

Thanks!