Understand Permissions in Customer Portal

• Overview
• Sections in a Portal Permission Set
• Points to Note
• Related Topics

Overview

Any organization will want authority over how their data is circulated within external users. When a systemized structure which decides the access and doable actions of application data comes into place, both the data management and security measures are ensured.

In Creator, Customer Portal Permissions enables you to define various permission sets that govern the accessibility of an application's components and its data through a customer portal. While providing access to required data, it also shields other application data from users outside the organization. You can create permission sets that provide data access at two tiers:

• Module Level - Permission to access a Creator application's components.
  • By default, a permission set titled Customer exists in all applications upon creation. When customers are initially being added, they are assigned to this permission set and can be reassigned if required. This set gives the customer permission to access forms, view the data added by all users (records) in the reports, and access pages.
  • You can also configure customized permissions, which enables the customer to perform actions such as accessing, viewing, editing, deleting records, and much more.
• Field Level - A set of Field Permissions is also available, which decides the read and edit access of each field present in your form.

Use Cases

1. Portal Permission to Access Report and Page - Say you have a construction company and have developed ties with a major supplier for different construction materials. You maintain the warehouse stocks and their movement in a Warehouse Stocks form and display their metrics in a dashboard. A portal will let the supplier (customer) into your application and allow them to access components according to the assigned portal permission set. To achieve this, permission to access the form's report All Warehouse Stocks and the Dashboard, and not any other components, should be assigned to the supplier when they are added to the portal.
   
2. Field Permissions with Restriction to Access Data-Sensitive Fields through Portal - Say you've built an Event Management application. While participants fill out a Join Event form, they are required to fill an email address field for which PII (data privacy) is enabled. By default, this field's values are not displayed in the Event Participants report for users other than the admins and super admin of the application. Say the vendor (customer) who is sponsoring the event wants to contact those participants using the entered email address directly to hand out goodies. In this case, a permission set that is configured to Show the PII-enabled field's data is assigned to the vendor. The field permission for the Participant Name and Email field will be set to only Visibility (records can be accessed but not edited) while all other boxes are unchecked.
   

Sections in a Portal Permission Set

There are two sections of permissions that need to be defined:

• Security Permissions - Set of rules that focus on handling sensitive data stored within records.
• General Permissions - Set of rules that focus on handling the access to application components and related actions.

1.  Security Permissions

Security permissions lets you decide if the listed PII-/ePHI- enabled fields in the Field Permissions popup can be configured.

• Show - When this is chosen, viewing PII/ePHI fields (Visibility) is allowed by default, which can be revoked if necessary. You can allow editing of the necessary PII/ePHI fields from the Field Permissions popup.
• Hide - WHen this is chosen, the PII/ePHI fields will be disabled in Field Permissions popup and cannot be viewed/edited by users added to an application. This option therefore hides the fields in the form and report.

2. General Permissions

A permission set has two different categories:

• Module level: Enable or disable the permission to access the application's components (forms, reports, and pages): view, edit, delete, import, and export records.
• Field level: Enable or disable permission to view and edit the fields in a record.

Points to Note

• While adding a customer, they get assigned to the Default Permission configured while creating the portal, which can be reassigned if required. To give a different value for the Default Permission, you can update it in the portal's settings.
• When an application sandbox is created, any changes to the assigned portal permission sets will reflect on the customers in the live mode only when the application changes are published.
• The number of portal permission sets that can be added to an application depends on your Creator plan.
• Customers cannot trigger API calls and therefore not use APIs for data manipulation.

Related Topics

• Add permission in portal
• Edit permissions in portal
• Duplicate permission in portal
• Delete permissions in portal