Live Forms Latest - This documentation is for Live Forms 9.0. Not for you? Earlier documentation is available too.

Skip to end of metadata
Go to start of metadata

The form/flow visibility feature is integrated with the Access Control feature. Both features open the same wizard where you may specify form/flow permissions or grant view/edit submission permissions to specific users/roles. The form/flow visibility property is discussed here. 

 

Setting Visibility for Forms/Flows

The Live Forms designer can specify the Visibility of a form//flow in two ways:

  1. Clicking the  Lock icon on the Forms Home Page or the Flows Home Page.
  2. Clicking the Access Controls section or the cog icon on the Form/Flow designer Properties Navigator when editing a form/flow.
  3. Click the Access Control tab.

Clicking on the icons or in the Access Control section of the Properties Navigator display the same wizard which can be used to set the Visibility of your form/flow.

When Who can start the form or Who can start the flow is displayed in the Permission field, the designer can select one of the dropdown choices to specify form/flow visibility. The default value for forms is Anyone (login not required) while flows default to Authenticated Users (login required). The choices for form/flow visibility are:

  • Anyone (login not required) - anyone can use it even if they are not logged in.
  • Authenticated Users (login required) - the form is usable to anyone who has an account (username/password) and is logged in to your tenant.
  • Designers/Owner Only - the designer user who created the form/flow (owner) can edit, test or use the form. They must be logged into Live Forms.
  • Custom - The owning designer always has access to the form/flow. Additionally, the designer may configure selected users and/or roles (i.e. users with these roles) to have runtime access to the form. Use this option to auto-start workflows programmatically.

The Visibility property has been removed from the form/flow properties pane in the designer. You can no longer change form/flow permissions in this manner. When Live Forms is embedded in another product such as  Atlassian's Confluence wiki, you do not have access to the icons described above.

The designer can grant form/flow access to explicit users/roles by selecting the Custom choice from the Visibility dropdown. Roles and users can be selected via an editable combo-box control. As the user types, Live Forms will try to find any roles and users in the tenant that contain the typed string. Up to 5 matches are displayed below the combo box. Selecting a role/user from the dropdown inserts the selection into the list.

Click Submit or continue with the next option in the Access Control wizard. 

The Expense Report in the above images can be used by anyone in the tenant with the role of Employee, Manager or Accounting, the user id of the Reviewer and the user Sue. Notice the Reviewer role is encased between curly braces. This is an example of a control template. Templates are like variables in your form that will be evaluated at runtime and replaced with the actual values entered. For templates to work, there must be a control in your form with the name given inside the curly braces.

The user, Jack, who has the role of frevvo.Publisher, is not a Reviewer for anyone in the company and of course, is not Sue, will be denied access to the form. He will see this error:

 

You can publish any form/flow regardless of whether it can be started by Anyone (No login required) or just the Designer/Owner. If Designer/Owner Only is selected, the person who created it or any user given the Who can edit the form/flow permission can edit it or test it. It is possible for more than one designer to collaborate on Forms/Flows in development if the form/flow owner (the designer that created the form/flow) gives this permission to other designers. However, if one designer is working on the form, other designers will be denied access. Form/flow owners can also designate the Who can view submissions or Who can edit submissions permissions to other users so two or more people may test the form/flow and view/edit submissions at the same time.

Similarly, if a form visibility is set to Authenticated Users(login required), only users with accounts in the tenant will be able to access the form.

Until you set your form/flow visibility to Anyone (login not required) all other users will see this error message when they try to access the form: " Error Access Denied. Authentication required. Are you trying to access a private form or flow?

A form/flow made public this way is accessible to anyone with the form/flow's URL. There are other methods of sharing forms that have increasingly higher levels of security. See form security for details.

If you set the form/flow visibility to Anyone (login not required) and users have begun submitting it, you'll need to use caution when modifying your form. If users access it while you are editing it, they will see error messages indicating that the page is being refreshed or that the form is invalid.  

You can mark your form/flow Designers/Owner Only until you are done developing it, which will prevent new users from accessing the form, but if users happen to be completing the form when you switch it from Anyone (login not required) to Designers/Owner Only, they will see error messages. A better approach if feasible is to edit the form in a copy of your application running on a staging server. You can then replace the current form with the new form by removing the original application/form/flow from the staging server and uploading the new application/form/flow.

ACL settings,set by the designer, are retained when you download/upload a form/flow/app to another designer user in the same or different tenant and when you copy a form/flow.

The designer can set other permissions, such as who can view/edit submissions for forms and flows via the Access Control wizard. Roles and users that can view the audit trail or be designated as flow administrators are specified through the same wizard.

Public forms that include the save/load feature or digital signatures will prompt the user with the login screen when they click to save or sign. These Live Forms features require a login.

 

 

  • No labels