It's a long story, but we have a group of account in SF that we'd like to make read-only.

Ideally, these records would...

  1. Remain accessible to the same people they were before
  2. No longer be editable
  3. Not allow any new relationships to other objects (e.g. opportunities)
  4. Be clearly marked as read-only
  5. Be switched into or out of read-only mode by users in certain roles

Options I've considered include:

  • Moving these records to a new user in a role created such that "normal" users are prevented from editing them.
  • Adding (a) validation rule(s).
  • Using different record types. (I've seen references to this online, but am not sure how to do it.)

The first two of these at least fail to hit several of our requirements. In particular, I'm struggling to work out how I'd achieve #3 and #4.

Has anyone done this before? What approach did you take?

  • 1
    Possibly use Approval.lock?
    – Adrian Larson
    Mar 27, 2017 at 15:14
  • Thanks for the suggestion @AdrianLarson - how would I go about this in practice? Would you (or anyone) be able to flesh this out into an answer?
    – Tom Wright
    Mar 28, 2017 at 8:30

1 Answer 1


It really depends on what you need to do and what your restrictions are. Without knowing any more, I'd recommend the following

  1. Create a new Account Record Type, call it "Read Only" (or whatever)
  2. Ensure all the fields in the Page Layout for that RT are also marked as "Read Only" and remove the "new" button on all the Page Layout's Related Lists
  3. Change the RT for the affected account to the newly created one
  4. Give permission to the users you want to change the RT of the account object

This approach is the simplest, but it has a number of drawbacks

  1. System Admins can still edit the accounts via the GUI
  2. The accounts can still be modified via Apex and/or Data Loader/API operations
  3. The relationship objects can still be created. You'd need VRs for each object to stop them from being created.

If this is not enough, then you can definitely go with Triggers, VRs or a combination of the above.

  • Hi Sebastian. I think I'm settling on a combo of record types and VRs (for the related items). I'm also thinking about using a Visualforce page block to add a prominent explanatory note to the top of the page layout.
    – Tom Wright
    Mar 28, 2017 at 8:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .