Public Forms Best Practices

Overview

Public Forms provide a lightweight, low friction solution that allows you to collect information from unauthenticated users, i.e. members of the public. Generally Public Forms are for data entry and do NOT  support retrieval and/or editing of existing Records.

Use cases for Public Forms include:

• hazard/incident reporting 
• collecting customer feedback

Public Forms are 'public' in the sense that they do not support user authentication; it is important to appreciate that by necessity Public Forms allow anyone on the internet (subject to your configured IP Whitelist) to create Records in your tenant. Furthermore Public Forms support the use of relationship pickers and can be configured to trigger Workflows. 

This article is general in nature and does NOT intend to cover any specific use-case for Public Forms; rather it outlines some of the best practices and key points to consider when using Public Forms.  

Also see:

• Public Forms Security Overview
• Getting Started with Public Forms

Requirements & recommendations

The following are key recommendations for implementing Public Forms, they are not currently enforced. Public Forms allows unauthenticated users to create records in your tenant, therefore to ensure data integrity and avoid potential data leakage ReadiNow strongly recommends adopting the following precautions: 

1. Use dedicated objects 
2. Use dedicated workflows
3. Avoid resource keys
4. Review IP Ranges

Use dedicated Objects

Failure to implement dedicated Objects for each Public Form introduces a risk of data contamination and increases a risk of data leakage. Dedicated Objects provide a means of quarantining dirty data.

Rationale

Data contamination could be the result of low quality form submissions. Using a dedicated Object for Public Forms provides the cleanest solution for segregating potentially dirty data from clean data. Dedicated Objects also make it easier to implement a dedicated workflow to triage/sanitise data submitted using Public Forms.

Public Forms support Relationships. For example: by setting up a relationship, an incident report form can expose a list of locations where an incident may have occurred. This necessarily exposes a subset of the information in your tenant to members of the public so they can select a location. However data leakage could occur if a relationship containing sensitive data is inadvertently added to the Public Form.

Comments

The potential for data leakage has been minimised by restricting the Relationship pickers so that they ONLY expose a single field, specifically the first text field in the Picker Report. 

In addition to using dedicated Objects, the potential for inadvertently modifying Objects that are publicly exposed can be further reduced by adopting a naming convention that highlights the Object's association with Public Forms. 

Use dedicated Workflows

Submitting  a Public Forms results in a Record being created, this provides an opportunity to trigger workflows. Workflows that are triggered by Public Forms should be simple and they should be dedicated to the Public Form's underlying Object. 

Workflows that run when a Public Form is submitted should focus on validating the integrity of submitted data and moving validated records from quarantine to operational data.

Avoid Resource Keys

Resource Keys can be defined by one or more Form Fields, their purpose is avoid duplicate records. Failure to avoid Resource Keys in Public Forms introduces a risk that Form submission will fail silently.

Ordinarily when an authenticated user creates a Record that violates a Resource Key constraint they receive a message: 'resource key already exists'. However, in the context of Public Forms that message effectively leaks data to an unauthenticated user. Therefore if form submission fails due to a Resource Key violation the submission will necessarily fail silently. 

Review IP Ranges

Public Forms respects the IP Ranges for your tenant. Users will be unable to access your Public Forms if they are using an IP address that is outside of the whitelisted IP Ranges. Whitelisted IP Ranges can be configured for your Tenant.  

Support for Field Features and Form Layout

Public Forms supports most fields and various functional configuration.

Fields that are NOT supported (and not displayed) by Public Forms are:

• calculated fields
• autonumber fields
• relationships
• documents

Fields that are supported but have restricted functionality are:

• lookups
  • picker is restricted to a single string field
  • manual entry is not supported
  • analyser is not shown
  • create new is not supported
  • display as dropdown is not supported
• choice fields
  • cascading choice is not supported
• images
  • image value can not be used in a calculation
  • default image not supported 
• date & date-time
  • keyboard entry is not supported for date entry
  • time does not support a default value 

All other fields are supported with some general configuration limitations as outlined below.

Support and limitations for field configuration

Supported field configuration:

• Mandatory fields are supported however non-mandatory are marked as optional
• Calculated visibility and read-only are supported (except for calculations based on the presence of an image)
• Min, Max values for number and date-time values are supported
• Min, Max values for string length are supported 
• Default values are supported
• Text pattern validation is supported
• Show Help is supported

Public Forms do NOT support the following field configurations:

• Form level validation
• Conditional formatting
• Horizontal and Vertical size
• Background colour
• Layout & position

Notes:

Layout controls such as containers are not supported. The Public Form runner supports basic layout by arranging form fields in a single column. When creating a form to be exposed as a Public Form, the best practice is to arrange fields in a single column without using containers.

Behaviour for containers has not been defined and containers should be considered as NOT supported.