The dialog for editing the access and availability configurations of a form can be opened by clicking the Access button   in the form menu.

Contents

General settings

Availability

The online checkbox lets you switch the form on-/offline. When set to offline, the form cannot be viewed or submitted. Use this for example when you wish to perform maintenance operations.

• Availability window
  This lets you limit the form's availability to a certain time range. When the form is not available, it can neither be viewed nor submitted. When no limit is set for available from and Available until, no restriction applies.

• Frontend server
  By default the form can be accessed on the master server. The form may be made available on a frontend server as well, if one has been configured for the client. If no frontend server is selected the form is only accessible on the master server.

If the availability of the form is set to offline, it is possible to define the behaviour of a process for the end user and inbox user. It can be decided whether the process is never available, whether it can be opened or whether it can be opened and submited.

Form login

This configuration area makes it possible to provide various methods with which users can or must log in to the form. Information of the logged in user can be accessed within the form & the status and workflow processing via user variables.

Above the configuration options there is a summary, which explains the configured form login again in short words.

Authenticated

By activating authentication, end users can be given a choice of login services via which they can or must authenticate themselves. For example, authentication can be forced via a specific login service. Furthermore, the form can be restricted to certain formcycle user groups. This makes it possible to configure the form access even more precisely and to allow or authorize only certain groups of people to access the form. If user groups are selected for restricting form invocation, people who have authenticated using one of the selected login services must be part of at least one of the selected user groups. See Users for more information on how to assign people who log in through configured login services to user groups.

Form password

To restrict access to the form, a form password can also be specified.

Without login

If users should be able to access the form without logging in, this checkbox must be activated. This option is only available if one of the options above for logging in is activated.

The described options for configuring the form access can be combined as desired depending on the use case.

Administrative protection

Client administrators can always edit the form, regardless of their user group.

This section lets you configure which users are allowed access to the forms. It consists of two parts:

Only editable by

Here you can choose which user groups may access the FORMCYCLE Designer and the change the settings in the configuration pages available from the form menu. When no user groups are selected, all users of the client are allowed to make changes to the form's configuration.

Only visible for

Here you can choose which user groups can see the form on the form overview page. When a user is allowed to edit the form, they can see it even if not explicitly configured by this setting. When no user groups are selected, all users of the client can see the form.

Data protection

When the option anonymize is activated, the user name of the user who submitted the form is not logged in the system's protocol.

One-time submission ID

Some forms may only be sent once per user or mail address. This forms allows you to configure an ID template that should contain variables, so that submitted forms with the same generated ID as already existing form records are rejected.

Assuming a form contains an input field tfMail, the following one-time submission ID can be used to limit form submissions to distinct mail addresses. [%tfMail%]

Every time a form is submitted, the one-time submission ID is generated from the value of the input field tfMail. If there exists a form record with this ID already, the submission is rejected and an error message is displayed. This error message can be customized by editing the HTML system template One-time submission error.

Available variables are form value variables and template variables.

In case the generated one-time submission ID is empty after all variables were replaced, the check is skipped and the form submission is not rejected. It is recommended you mark all form fields for the one-time submission ID as required.

The one-time submission ID must not be longer than 1024 characters. If possible, set a length restriction on the corresponding form fields in the FORMCYCLE Designer. When changing the one-time submission ID template, you can update all existing form records with the button to the top left. In case this result in duplicate IDs, the update process is aborted and all conflicting form records are shown. If the ID template is empty and an update is performed, all existing IDs are removed.

Settings per state

These settings can be configured separately for each state.

Advanced options: deletion & review

Process-Link without login

When this option is enabled, form records with this state may be viewed by anonymous users, assuming they have got a link to the form with the process ID.
When this option is disabled, users need to sign in in order to gain access to form records.

Form record deletable

Whether a form record with this state can be deleted in the inbox.