We spent a long time adjusting the design of our social app platform, <a href="http:&#x2F;&#x2F;qbix.com&#x2F;platform" rel="nofollow">http:&#x2F;&#x2F;qbix.com&#x2F;platform</a><p>Basically we have a solution where users have accounts, and their contacts can have labels. They can assign access based on the labels, or to individual users. When the user represents an organization the labels basically represent roles for permissions. The same system is used for both people sharing with friends and organizations sharing with various members.<p>Now, as a user you can also invite others. Then a unique invitation link is generated, and securely delivered to an endpoint such as an email or sms. The recipient may choose to follow the link, which confirms their email address or mobile number. From there, we see if they already have an account or create a new one without any action on their part. (Password can be set up next time they try to log in with that email address or mobile number.)<p>It is at this point that we look at the access granted in the invite. We make sure that the inviting user has at least those permissions (so you can&#x27;t eg send yourself an invite to survive getting banned from a chatroom) and then grant them to the invited user via the access system.<p>We have three levels of permissions: readLevel, writeLevel and adminLevel. Each ranges from 0 to 40, signifying various things (eg a writeLevel of 40 lets you delete that whole social collaborative thing).<p>So the invitations are kind of like capabilities. And we do a check upon the person redeeming the invitation. But once the user accepts the invitation, they have an id and we use our general system of access control, so admins can set up the access for various types of contacts.