Guest Access Criteria

Overview

Data stored in AgileApps is secure and only authenticated users can create and view records. Without valid permissions, you cannot get access to this data. This feature allows a guest user to perform CRUD operations on an object without any authentication or login to AgileApps. It works on criteria-based permission models.

A use case scenario for this feature is a flight reservation system. Here, a user can view the available flights for a destination as an anonymous user. However, to book a flight, the user would need to sign up or provide certain credentials.

Who can use this feature?

AgileApps allows for automatic login for the guest user. Guest user is a standard platform user with ‘user id’ as 7. The authorization should be configured by the Tenant Admin in the form of a formula in Object Properties.

Note: This feature is not available in a sandbox environment.

Prerequisites

To use this feature, the sub-domain should be enabled. The guest user should access AgileApps using a sub-domain. For more information about enabling a sub-domain, see the Tenant Configuration section in Service Configuration.

Basic Flow

1. To configure this feature at the object level, go to Settings > Account Management > Company Information. Here, under Session Management, set Enable Guest Access to Yes as shown in the following figure:

2. To configure at object level, go to Settings > Customization > Objects > {object} > Object Properties > [Edit] > Guest Access Criteria, select the Allow Guest Access option as shown in the following figure:

Note: If an object is enabled for guest access, then all the fields for that object are open to guest or public access. The application designer can choose which actions to permit for the guest user.

The functionality of Guest Access Criteria is similar to Custom Access Criteria. Guest Access Criteria lets you specify who can access/update/delete individual records, based on the data in the record, characteristics of the current user, and any other available information. You can define a set of expressions, one for each action that can be performed on a record. Actions include:

• Add
• Update
• Delete
• List View
• Record View

For each action, the Formula Builder is used to create an expression. The fields mentioned in the Formula builder should be present in the current object. When the expression evaluates to true for an action, the Guest User can perform the action. An example for the formula builder is as follows:

Note: If no formula is defined, then the default value for the CRUD action is false. The guest user cannot perform the said action.

Considerations

• During Run Time, when the Guest Access Criteria is Enabled, a Guest User session (with user id as '7') is created in REST API or Solution API end points. So, all the operations are performed with logged in user id as '7' (also referred to as GUEST USER).
• By default, all the records created by the Guest User has owner_id value as '4' (open ownership). If no value is provided beforehand, the values for created_id and modified_id fields are set to '7' (Guest User).
• The View Action is considered as true when Record View criteria or Update Criteria is evaluated to TRUE.
• If the Guest User can view a record, then the Guest User can download or view the content of file and image fields in the record.
• By default, the guest user has access to the Default Form Layout. For information related to custom layout in components, see Custom User Interface documentation.
• When the Guest User access permission is evaluated to false for an object or record, then the operation fails with an error message, "User Not Logged-in", 401 as HTTP status code.
• When a session time out happens for a logged in user, the guest user session is created only when a valid userId is not available in the Cookie.
• Guest User does not appear in the Users List. The Guest User is a member of My Team.
• Only /record in the REST API is accessible for the Guest User.
• The guest access is only available for the following record form components and list view components:

• ace-record-table-view
• ace-table-grid
• ace-object-views-list
• ace-record-form
• ace-record-actions (only Delete is available)

Note: Accessing any other API calls and components apart from the ones listed in the preceding two points, results in failure with 401 HTTP status code.

• For the ace-record-table-view and ace-table-grid components, when the guest access is evaluated to false, the response is zero records and 202 as HTTP status code.
• The ace-object-views-list component displays all the views permitted (global views and views available for My Team) to the guest user.

Limitations

• This feature is not available for Service Desk case and case type objects along with Task, History, Attachment, and Articles Posted in Categories objects. The public/guest access is managed by Service Portal Configurations for case objects.
• Guest user cannot execute any Macros. Also, cannot start or stop processes, or see any tasks or attachments. If they try to perform any of these operations, they will get a permissions error or Error 401.