In our organization, accounts aren't owned, and teams are used to manage sharing of accounts. We're planning on having all accounts owned by a single generic user. According to the architect resources for record ownership skew, this isn't ideal, but if you have to do it, the best way is to have the generic owner have no role.

So that was our plan, but alas, you can't have an account with customer portal users owned by a user without a role.

Reading the docs it seems like the best place then would be to have the generic owner with the root role, since that leads to the fewest role-hierarchy sharing calculations.

But now I'm wondering what impact this could have with customer portal users.

Has anyone encountered the need to have all (nearly) accounts owned by the same user in an organization with customer portal accounts and could shed some light on best practices here?

1 Answer 1


I can't advise as to a best practice, but I can share some observations that I've made.

I worked on a team that built one of the first communities. We began when the newest sharing models hadn't yet been released. As a result, our security model changed several times over before we completed the project. Initially, we'd planned for community users to be able to take ownership of various records but later found that wasn't necessary in order for them to create or edit records they needed access to by using sharing groups and permission sets. The community was built to support outside contractors where all the Contacts were under a single internal company account with a single contact recordtype. They all reported to a limited number of Managers/Owners. We're talking about two thousand or so contractors in total with perhaps 25 Owners.

As I'm sure you're aware, the Community User's Contact Owner or whomever creates them, also needs to have a Role assigned to them. It's the Role of the User's creator that essentially provides the equivalent for a Community User when they're created. That's the best analogy I can make to what seems to happen since I don't know any other way to try and explain how they're created without a having a Role assigned to them. There's some sort of inheritance that's passed from their Owner or Creator's Role that seems to have an effect on what they can access, or so we seemed to observe during our development.

It may have simply been that because the Contact's Owner owned the Accounts they worked on, that's part of what provided them access without explicitly needing it assigned to them at one phase in our development. We eventually went to sharing groups and permission sets, so its possible that my observations could have been made during a transition period in our security model. I wasn't responsible for handling the security part of it so can't say for certain. Things have also definitely changed with the many revisions that have been released related to sharing since that project was completed.

My only concern with your plan would be Community Users that are owned by a User who does not have a Role. We worked around a related issue in our triggers by assigning ownership of records to the Admin when a Community User's Id couldn't be located (we were working from ContactID to Portal UserId). So, will that require your Contacts to be owned by an Admin? Its possible you may find a way to work around that issue in the sandbox. That would be new ground for me that I'd simply be guessing on that I'd want to test thoroughly before trying to implement.

I suspect the easiest way to work around this would be to start by having all Contacts owned by the User who owns all Accounts, then set up sharing groups and permission sets for each Account Team. I'm confident you don't want to hassle with going deeper into your organization unless you only have a few Account Teams and can easily break them into sub-account teams. Whether the sharing groups will impact the issue of Roles will be something you'll need to test. So long as no one takes ownership, I'd expect you'd likely still be safe. Again, only testing will reveal what's going to happen.

As an aside, something to be aware of is that any temporarily disabled/inactive Community Users you might have in your records can wreak havoc with your triggers!

I'll be interested to learn what you discover and hope you'll share your findings.

  • This is really helpful, and I'm glad I can take your experience into account. We're currently in testing with the generic owner and will follow up with any performance or community/portal access issues that pop up. Thanks @crmprogdev Nov 14, 2014 at 18:58
  • Hi Ralph, We are in same scenario now and we are using community plus licenses. How were your performance results after above change ?
    – sf_user
    Jan 3, 2018 at 21:14

You must log in to answer this question.

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