Record-based security in Adxstudio Portals that applies to individual records is provided by using Entity Permissions.

While permissions to change and access URLs in a portal sitemap is granted via Content Authorization, site managers will also want to secure their custom web applications built with Entity Forms and Entity Lists.  

In order to secure these features, Entity Permissions have been introduced which allow for granular rights to be granted for arbitrary entities and for record-level security to be enabled via relationship definitions.

  This documentation applies to Adxstudio Portals 7.0.0007 and later versions.
If you are want to display Notes in your Portal Explicit Entity Permissions are required for any notes to appear on the portal. For read and edit, the 'Read' and 'Write' privileges must be granted. For create, two permissions must exist, a permission with the 'Create' and 'Append' privileges must be granted for the note (annotation) entity, the second permission must be assigned to the entity type the note is being attached to with the 'Append To' privilege granted. Notes for Entity Forms

Adding Entity Permissions to a Web Role

Entity Permissions are added to Web Roles, allowing you to define roles in your organization which logically correspond to the privileges and concepts of record ownership/access that are introduced with Entity permissions. Remember that a given Contact can belong to any number of roles and a given role can contain any number of Entity Permissions.

In order to add an Entity Permission to a Web Role, navigate first to the Web Role you wish to add the permissions to. Web roles for a website can be found in the CRM in either Portals > Web Roles or Portals > {your portal} > Web Roles.

Click to Add an Existing Entity Permission.  From there you may click to create a New Entity Permissions Record.

When creating a new Entity Permission record, the first step is to Determine the Entity that will be secured. The nest step is to define Scope, as discussed below, and in the case of any scope besides Global, the Relationships that define that scope must be specified. Finally, determine the Rights that are being granted to the Role via this permissions. Note that rights are cumulative, so if a user is in one role that grants Read, and another that grants read and update, the user will have read and update to any records that overlap between the two roles.

Global Scope

If a Permission record with Read permission is granted to a role that has global scope, any Contact in that role will have access to ALL records of the defined Entity in the CRM.  i.e. they can see all leads, all accounts, etc. This permission will be automatically respected by any Entity Lists; essentially showing all records according exactly to the CRM view(s) that has been defined for that list. Further, if a user attempts to access a record via an Entity Form that they do not have access to, they will receive an permission error.

Contact Scope

With Contact Scope, a logged-in user in the Role for which the permission record is defined will have the rights granted by that permission only for records that are related to that user's contact record via a relationship that is defined in the CRM.

On an Entity List, this means a filter will be added to whatever CRM view(s) are surfaced by that list, which retrieves only records linked to the current user directly (this relationship can be thought of as "ownership", "management rights", etc. if this helps, depending on the scenario.)

Entity Forms will only allow the appropriate permission for Read, Create, Write, etc. if this relationship exists when the record is loaded.

Account Scope

With Account Scope, a logged-in user in the Role for which the permission record is defined will have the rights granted by that permission only for records that are related to that user's parent account record via a relationship that is defined in the CRM.

Self Scope

Self Scope allows you to define the rights a user has to their own Contact (Identity) record. This allows users to use Entity Forms or Web Forms to make changes to their own Contact Record linked with their profile.  Note that the default "Profile" Page has a special built-in form that allows any user to change their basic contact info and pot in or out of marketing lists. If this form is included in your portal (which it is by default), users do not require this permission to use it.  They will require this permission to use any custom Entity Forms or Web Forms that target their User Contact Record, however.

Parental Scope

In this most complex case, permissions for an entity are granted that is a relationship away from an entity for which a permission record has already been defined.  This permission is actually a child record of the parent Entity Permission.

The Parent Permission Record defines a permission and scope for an entity (Probably Global or Contact Scope, although parent is also possible). That Entity may be related to contact (in the case of Contact scope) or Globally-defined. With that permission in place, a Child Permission is created that defined a relationship from another entity to the entity defined in the parent relationship.  

Thus, users in a web role that have access to records defined by the parent entity permissions, will also have rights as defined by the child permission record to records related to the parent record.

It's a mouthful no matter how you explain it, so let's give an example.


Securing Entity Lists

In order to secure an entity list, you must use Configure Entity Permissions for the Entity for which records are being displayed, and also set the "Enable Entity Permissions" boolean value on the Entity List record in the CRM to true.

The act of securing an Entity List will ensure that for any user that accesses the page, only records that they have been given permission to are shown. This is achieved by an additional filter being added to the CRM views that are being surfaced via the list.  This filter will filter for only records that are accessible to the user that is logged In.

Note that if NO records are available, then a message indicating this will be shown when the list is loaded.  However, good website design determines that if a user is not in a role that has any permissions for the entity (i.e. there will never be a situation where they should see any records), they should also not have access to the page at all, and thus the page should ideally be protected with Webpage Access Permissions