I have community enanbled in my org. As you all know, once someone registered as a community user, Salesforce will create a Contact for it. Now I would like this community user to update certain fields in Contact.

I understand that it can be achieve by creating a visual force page then pull out the contact field so that the community user is able to update from there.

Now the problem is, we have restricted community users on Contact object, they have no 'Read' permission on Contact so certainly my visualforce page will show blank.

The reason why I want to restrict community user is because in our community site we also have the global search function, if I do not restrict community user on Contact object, the global search will return contact as well which is not comply to our security. We do not want each community user to see other's contact's profile. It's P&C.

So now i would like to know is there any way i can:

1) modify the global search function not to return contact results since it is a standard smart search

<iframe scrolling="yes" height="1000px" frameBorder="0" name="theIframe" src="https://mycomp.force.com/search/SmartSearch?str={!$CurrentPage.parameters.msg}" width="1020px"></iframe>

2) a way for community user to update contact's field without 'Read' permission on Contact.


1 Answer 1


2) a way for community user to update contact's field without 'Read' permission on Contact.

Create a custom object that they have read and write permissions to that has the same fields in that Contact does which you want your portal users to update. You can then use an After Update trigger to update Contacts whenever a Portal User updates their information to the custom object.

You'll want 2 triggers. One that syncs After Insert and After Update from Contacts to the Custom Object and another that syncs After Update (You may want After Insert too, depending on how you configure things) from the Custom Object back to Contacts.


Record ownership, sharing and field level security are also important aspects you need to address which I didn't discuss. In a community they can be handled in a number of ways, in fact too many ways for me to cover here. In this case, on the Custom Object, the sharing model would be set to Private. The portal user would have read/write access to the Object, but would only have read/write access to the records they actually own. All other records which they don't would be hidden. In this manner, other records shouldn't be visible to them in a Global Search. At a minimum, they wouldn't be able to see the fields they don't have at least read-only access to. Remove read-only access to the "Name" field, and they won't see that either.

This may be the source of your issue with Contacts. Typically a a contact record has an owner other than the person who's the contact. You didn't say what type of community user license you're using, but what we did in a similar situation was set up sharing so that a Portal User could edit certain types of records (like their contact info) by setting up a sharing model where the Owner of the Contact shared edit-only privileges with the record with the Portal User.

I didn't set up the details of that sharing model, so can't tell you exactly how it was done. I know that any records created by the portal users (this was a high volume customer portal/community) were actually owned by the Portal User's contact owner. That wasn't the way we originally architected the community security model, but its how it was configured when it went into production as things changed between the time communities were made available and the time we finished the project, plus we learned a lot along the way.

So, in general here, I think the issue for you is that you want to make certain your Portal Users don't have records shared with them which they can't edit or don't need to see. If you do that, even if they come up in a global search, they won't be able to view them.

  • hi! if i give read & write permission to that custom object then my global search (smart search) will return result from this custom object also right? or it wont? Jul 3, 2014 at 5:57
  • I neglected to discuss two other important aspects of this which is sharing and field level security. See my edited answer. I suspect this is also the source of your issue with smart search.
    – crmprogdev
    Jul 3, 2014 at 13:14
  • I really think that using the Sharing rules would prevent the community users seeing the contacts that are outside their area, but I would want to test that first before guaranteeing it. One issue with using custom objects is there are limits on the number of these that a community user can view (10 for most profiles without requesting the limit to be extended).
    – Dave Humm
    May 16, 2016 at 9:04
  • As with all things, it's essential that they be tested before implementing them in production. An issue with Global Search SOSL queries can be that they don't always run with sharing like most SOQL queries do. They tend to run in more of a system mode. Testing would definitely be essential. If he were running his own class, it would be easier to ensure enforcement of sharing.
    – crmprogdev
    May 16, 2016 at 12:15

You must log in to answer this question.

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