This is the scenario:

I have a custom object myObject__c and two VF pages which have the object as standardController and MyObjectController.cls as extension.

The class is a StandardController that has 2 methods. The first one is called from the first page and it redirects you to the second page and the second method does the same, I mean, it redirects you to the first page. But they don't do anything else, any kind of DML operation.

I have overriden also "view" with the first VF page, so everytime I open a myObject__c record, I can see my first VF with the button that redirect me to the second page.

Now, I create a permission set that has only Read Access to myObject__c, Tab access and also, to the 2 VF pages.

If I try to test it as an user with only this permission set and an empty profile (only access to standard objects) I'm not able to navigate from the first page to the second one and viceversa. However if I add myObject__c Edit access to the permission sets, it works properly.

Does anyone know the reason? Or what am I doing wrong?

Many thanks in advance.

2 Answers 2


Augustina - I would definitely test this using just profiles first and then with permission sets to ensure there isn't a discrepancy between the two. If it works with just read on profile (no permission set assigned) but read/edit on permission set (no access granted on profile, then there's probably a bug that needs to get filed with support. However, if it's consistent between the two where read/edit is required regardless even though you're not performing DML, than there's a whole other reason and we need more information here. AFAIK,there's no reason I can think of why Edit would be needed at this point unless you were trying to perform some additional DML action like changing the owner.

  • 1
    Hi, Adam!!! I tried with only Profile and it didn't work either so I would take a look at our code. Thanks for the advice. Apr 29, 2013 at 7:44
  • @AgustinaGarcía if this answered your question then stackexchange convention would be for you to mark it as the accepted answer (and it gives Adam points for being awesome). Apr 29, 2013 at 23:40

Here's what's happening:

Standard Profiles

The platform provides the following set of standard profiles in every organization:

• Read Only

• Standard User

• Marketing User

• Contract Manager

• Solution Manager

• System Administrator

Each of these standard profiles includes a default set of permissions for all of the standard objects available on the platform.

When a custom object is created, most profiles (except those with “Modify All Data”) don't give access to the object. You can find more detailed descriptions of all the standard profiles in the online help, but the important thing to know is that you can never edit the object permissions on a standard profile.

In essence, none of your standard profile users can see the custom object with the exception of you or someone else who's a system admin. That's why the permission set is necessary to begin with. As for why a read only user who has the permission set enabled for them still can't see the pages/custom objects, I'd suggest you check to see if one of your controllers has the ability to call another controller that has DML capabilities. I'd also suggest you look at any sharing that's configured for them as well which might affect their access.


I just finished looking at Chapter 7 of the material I referred you to again myself. I'm confident that you need to at least enable read-only field level access in the user profile for the user to see the custom object and the particular fields you want them to see. There's also a separate read-only access checkbox for your VF pages that will also need to be enabled for that user profile as well. Its possible those pages require a higher level of access than the profile/permission set combo is currently giving your user.

SF works based on a combination of profiles, permission sets and record sharing with the latter done primarily through role hierarchies (plus preferably minimal manual sharing). SF is very Profile driven, but all 3 are required for it to operate as intended in an org of any size. I believe you'll encounter numerous problems should you attempt to only use Permission Sets and not leverage them with Profiles and Roles

Everything in SF, with the exception of the Read-only User Profile, builds on the Standard User Profile as the most restrictive profile, then expands permissions from there. The Custom User Profile you've created needs to expand on your Standard User Profile to have read-only access to this new custom object. If you've omitted anything from your Custom User Profile that's in your Standard User Profile, that could be part of the problem you're having. If all your users need access to this custom object and certain custom fields within it, it would be normal practice to grant that through a field level security in a custom version (clone) of your Standard User Profile; not through a permission set.

  • Sorry, I didn't explain myself well. I have a new user related to a custom profile with any kind of access to myObject__c, because I wanted to give access throw permission sets. And the right that I wanted to apply to myObject__c was just Read acces as I don't perform any other accion, just read the record and navigate from one pag to another. My question is why I also need Edit right to do this acction when I don't update my record. Anyway, thanks for your response. Apr 25, 2013 at 6:59
  • Does your custom profile give access to custom objects? What I was trying to explain is that the issue may be related to how your VF page is set-up. What profiles are allowed to access your page? Are there other objects on your page that the user with that profile might not have have access to without read/write permissions on custom objects? Its entirely possible that the the controller for the pages has the capability but doesn't call on those pages, another controller with DML operations or SOQL queries to data the user profile can't see w/o the read/write perms. Worth investigating.
    – crmprogdev
    Apr 25, 2013 at 15:26
  • Thanks for the clarification. My profile doesn't have any kind of access to myObject__c or VF pages. I give them via permission sets. And no, there is no other call to another controller with DML. Anyway thanks for the suggestion, and I will double check again just in case there is something in the background and I didn't realize it. Apr 26, 2013 at 9:56
  • I'm fairly confident the problem is the user profile doesn't have at least read-only access to the custom object. The entire subject is explained very well in Chapter 7 of the Force.com Platform Fundamentals PDF. Being a fairly complex subject, the document addresses it in far greater detail than I can try to cover here. As such, I'm confident you'll discover the root cause of the issue you've encountered within the material in that particular reference.
    – crmprogdev
    Apr 26, 2013 at 14:41
  • Thanks for the reply, you are helping me a lot. I tried but this is not the problem. Actually we want to not to use Profiles anymore and just use Permission set from now forward, so I would be able to set objects rights only on Permission Sets. Apr 29, 2013 at 7:28

You must log in to answer this question.

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