I have a custom field which I do not want even 'System Admins' to update both via manually or data-loader. It needs to be only updated by trigger or via workflow rule. Is there any way to achieve this ?

If I put validation rule then it will fire with trigger too. Any workaround to achieve this ?


  • 1
    What do you mean when you say it can be updated via Trigger? Triggers are fired on record update. – RajeshShah May 5 '16 at 12:13
  • @RajeshShah: Yes I want to update the field only via trigger or workflow rule. I have a 'Last Status Change' field on case which updates only when the status of the case is update. This happens via workflow. Since last week there is a weird situation happening. The workflow is not firing only for few records in production only during record creation. Those are any random records. In sandbox everything goes well. Due to this one of my functionality is breaking. So now I am trying to update this via trigger at time of record creation and via workflow at the time of Status update. – Ruchi May 5 '16 at 17:11
  • so you are trying to patch data in the database but the patching causes unintended side effects? Can you turn off those side-effects temporarily (e.g. deactivate the workflow, deactivate the trigger, ..)? Any DML will execute the trigger, conditional logic in the trigger can avoid other DML or implicit saves of changed fields;Standard/VF UI and Data Loader are merely clients of the domain layer (triggers) – cropredy May 6 '16 at 4:40
  • @cropredy: I cannot deactivate the trigger/workflow as it constantly needs to run on cases for the reporting purpose. The trigger is inserting new records on a custom object whenever the Status of a case is changed. Deactivating them will then hamper the reports. As of now I have updated the trigger to handle the exception which is occurring in production. But we doubted that users are making the fields as blank manually due to which issue is occurring. So to avoid any such condition in future I had want to make the field completely Read-only for all the users. – Ruchi May 6 '16 at 6:27
  • The only solution I can think of is create a dedicated user and use system.runas for that particular user and bypass all VR for this user – C0DEPirate May 6 '16 at 8:19

@Ruchi -- Let's go back to First Principles:

  1. All changes to the database occur in the context of some running user
  2. A change to the database can be prevented by a Validation Rule (VR) or addError(..) method on the record being updated via an insert or update
  3. The VR or addError is executed using the running user's permissions

So, a sysad submitting a change to a field via any client to the SFDC domain layer (triggers/VRs) will, unless prevented by the VR or trigger, always be able to update the value because a sysad has Modify All Data permissions.

When businesses want to prevent sysads from altering SFDC data, they introduce VRs and/or addError(..); otherwise, they trust the Sysad to be responsible.

So, how might you change the database using a different running user than the user that submitted the transaction? Put the request for change in an object and schedule a job that runs under a different user to do the updates asynchronously. How this would solve your specific problem is unclear to me as ultimately, there has to be business logic that prevents the user from entering a transaction that can corrupt the database


Here is the solution:-

Restriction for:-

1) Manual Update - We can make custom field read-only on Page Layouts.

2) Data Loader - We can add a condition in existing Apex Trigger to compare old and new values for custom field. If old and new values differ which mean it was updated by Dataloader and we can throw an error message.

Apex Code:-

trigger RestrictValue on Account ( Before Update ){

for ( Account a : Trigger.New ){

if ( Trigger.OldMap.Get().CustomField__c != a.CustomField__c)
    a.addError('You can not update this field by Data Loader');
    a.CustomField__c = fieldValue ;

} }

In the above code, trigger will take care of update if not using data loader because the old and new value will be remain the same until it reaches the line of code where we actually updating the value of custom field.

3) Workflow Field Update :- We need to compare old and new value in Workflow condition before updating the new custom field value.


  • Hey @Shanu Aggarwal have you read the question carefully.he wants to restrict system admin also.So the system admin can access even if you make a field read only in page layout level & profile level also.So your answer won't work – Pavan tej May 5 '16 at 11:22
  • @Shanu : If I restrict the update of field via trigger then wont it even restrict the workflow rule also to make the updates ? Making Read only on Page layout will not restrict the Admins. – Ruchi May 5 '16 at 12:20
  • @Ruchi It wont restrict trigger to make the updates because Workflow Field Updates always run later in the order of execution. – iamsfdc May 6 '16 at 8:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.