Home / General reference / Process / Activities / Form

Form

Article • 02.08.2022 • 14 minute(s) to read

Form

Form Activities present input Forms to Users for entering, modifying, inspecting or signing data. The Forms are composed of Form Controls providing various interaction methods like Buttons, Text Fields, Checkboxes, etc.


There are four different way how Form Activities can be left and the Process continued. The fist three ones are:

  • Action - Actions are triggered by Users when they finish a Form. Actions are configured in the Form Controls menu.
  • Timeout - Timeouts are triggered when their duration is elapsed or the specified point in time is reached. Timeouts are configured in the Timeouts section of the Form Activity Configuration.
  • External Trigger - Forms can be send to external contributers not having a User for the Novunex Subscription. In that case, the API has be to used to compose an URL. With this URL it is possible for anyone to access the From in a Web Browser and complete the From Activity.

Actions, Timeouts and External Triggers share the same logic for their Outcomes. All have Outcomes associated with them by linking them manually with Outcome names. If multiple Outcomes have the same name, all Outcomes are associated with the corresponding Actions, Timeouts or External Triggers. When Actions, Timeouts or External Triggers are set off and the Form Activity is left, the Script of all associated Outcomes will be evaluated. Each Outcome with a script evaluating to true will be followed. If more than one Outcome script evaluates to true, the Process is paralleled. If no Outcome script evaluates to true, the Instance will be ended by entering the closed-state.


Delegations are the fourth way to leave an Activity. Here, the Outcomes have to have a specified name, in contrast to Actions, Timeouts and External Triggers:

  • Delegation - Users can delegate the Form to other Users Groups or individual Users. To which Users Groups and Users a Form can be delegated to is configured in the Delegation filter user groups and Delegation filter users of the Form Activity SETTINGS. When Users complete the Forms delegated to them, the Form Activity is left by the Outcomes called Delegate. Thus when working with Delegations, at least one Outcome called Delegate must exists. If multiple Outcomes have the name Delegate, all Outcomes are associated with the Delegation. When the Form Activity is left, the script of all associated Outcomes will be evaluated. Each Outcome with a script evaluating to true will be followed. If more than one Outcome script evaluates to true, the Process is paralleled. If no Outcome script evaluates to true, the Instance will be ended by entering the closed-state.

Delegations obviously change the current User of a From, which must be kept in mind if your Process needs to keep track of the current User. In this case, you have to update the current User information in your Process after a From was left via the Delegate Outcome. This can be done by reading the new current User from the Variable configured in Delegation to variable.

Delegation can be disabled by:
Hiding the delegation button on the Task List Widget Remove any Outcomes with called Delegate Set Delegation filter user groups to an empty group and leave Delegation filter users empty Use a Variable to set Delegation filter users to the current user and leave Delegation filter user groups empty


Row Level Security is another special features of the Form Activity, since it only applies to Form Activities. Therefore, all other Activities can work and manipulate data without any restrictions by Row Level Security. Hence, you have to make sure that the Variable backing a Form Activity has the correct Row Level Security granting access to Users working with the Form.

Activity config

General

General behavioral configuration, shared with most other activities

  • Name - Name of the Activity.
  • Version - Version of this Activity used in the Process. If a new version of this Activity is available and you want to use it, you have to manually update the version here. When a new Activity is added to the Process, automatically the latest version is placed.
  • Timeout in second - Once this time is elapsed, the Activity will be closed and the Process continued. The default Timeout is two minutes. The timeout can be shortened and extended by entering a custom duration. The option Timeouts in the FROM section offers a more fine-grained timeout configuration than this general timeout and is therefore preferred over this option. However, if the Activity is left after a timeout configured here, the first Outcome is followed. If multiple Outcomes have the same name as the first Outcome, all of them are followed. However, a continuation after a timeout does not effect the Outcome Scripts, meaning only Outcomes with Outcome Scripts evaluating to true are followed.
  • Hide in process graph - Controls if the Activity is hidden (Yes) or shown (No) in the Process Graph on the Execution Screen.
  • Continue on error - If this is set to Yes, the execution of the Instance continues even if the Activity failed. If set to No, the Instance fails when the Activity fails by entering the faulted-state. In the case of a continuation after an error, the first Outcome is followed. If multiple Outcomes have the same name as the first Outcome, all of them are followed. However, a continuation after an error does not effect the Outcome Scripts, meaning only Outcomes with Outcome Scripts evaluating to true are followed.
Form

From Activity specific configurations

GENERAL

General interaction configuration

  • Disable activity - Disables (Yes) or enables (No) the Activity. When disabled, the Activity is not executed and passed like a Connection by following the first Outcome. If multiple Outcomes have the same name as the first Outcome, all of them are followed. Disabling the Activity does not effect the Outcome Scripts, i.e., still only Outcomes with Outcome Scripts evaluating to true are followed.
  • Retry on error - If set to Yes, an automatic retry is executed up to ten times. If set to No, no retries are done. Retries are issued when the Activity failed so that the Instance would enter the faulted-state if the retry is disabled.
  • Additional text for task list - Description of this Activity shown to the Users in their task list. You can enter this text directly or use Process Context Expressions to compile it.
  • Process graph location - Set the location of the Process Graph to either the Right or the Top section of the Execution Screen. The Process Graph shows the Process Graph Widget and the Process History Widget, if the location is set to Right. If the location is set to Top, the Process Graph only shows the Process Graph Widget and does not show the Process History Widget.
  • Hide process history widget - Hides (Yes) or shows (No) the Process History Widget in the Process Graph. This option is only available if the Process graph location is set to Right. If the Process graph location is set to Top, the Process History Widget is not shown and this stetting is hidden from the configuration. Furthermore, the Process History Widget is never shown in the Process Debugger, regardless of this setting.
  • Hide form task in task list - Hides (Yes) or shows (No) the Form Activity on the Task List of the assigned User or Users.
  • Hide process graph widget - Hides (Yes) or shows (No) the Process Graph Widget in the Process Graph.
  • Additional text for task list - Description of this Activity shown to the Users in their task list. You can enter this text directly or use Process Context Expressions to compile it.
  • Task due date - Specifies the due date of this Activity shown to the Users in their Task List. You can enter this text directly or use Process Context Expressions to compile it.
FORM

Form design and configuration:

  • Form design and action - Edit opens the Form Designer allowing you to design and configure the actual Form and its Form Controls.

  • Instructions - By clicking Edit a text editor is opened allowing you to enter detailed and formatted descriptions of the Form. The Users can read the instructions in the Process Graph Widget.

  • Owners - Edit opens the Task Owners configuration. Here you can configure whole User groups and individual Users that get the From assigned in their Task list. There two ways to specify the desired User groups:

    • Add User Group - Add a User Group by specifying the User Group’s name directly
    • Add Variable - Add a User Group by specifying a Variable in Process Context Expression Notation holding the User Group’s ID. This can be a Context Variable or an Attribute specified in Process Context Expression notation like #[MyEntityVar.MyGroupAttribute.Id] or #[MyContextVar] containing the User Group ID.

    Similarly, the Users can also be specified in two ways:

    • Add User - Add a User by specifying the User’s name directly
    • Add Variable - Add a User by specifying a Variable in Process Context Expression Notation holding the User’s ID. This can be a Context Variable or an Attribute specified in Process Context Expression notation like #[MyEntityVar.MyUserAttribute.Id] or #[MyContextVar] containing the User Group ID.

    allows you to delete any configured User Groups and Users again.

    If no User Groups or Users are configured, all Users in any Group will see the Form in their Task Lists.

  • Timeouts - Edit opens the Timeout configuration. This is preferred over the Timeout in second configuration on the General behavior configuration, since it allows a more fine-grained configuration of the Timeout. By clicking Add Timeout a new Timeout can be added:

    • Type and Value - The Type sets how the Value has to be specified:
      • Type set to Minutes - Value must be a positive integer specifying the Timeout duration in minutes. The duration starts running, when the Instance enters the Form, which might be much earlier that when the User actually opens the Form. This type of timeout is reset, when the Form is delegated. However, it is not reset when the Form is re-entered without a delegation. If you want to reset the Timeout when the Form is reentered, you have to use the Variable type and calculate the expiration time explicitly.
      • Type set to Specific date & time - Value is a specific date and time entered directly that sets when the Timeout runs out.
      • Type set to Variable - Value has to be a Variable or an Attribute specified in Process Context Expression notation like #[MyEntityVar.timeout] or #[MyContextVar]. It has to hold a Date Time specifying the point in time when the Timeout runs out. Using a Process Context Expression to calculate the time here is not allowed, i.e., it has to be precalculated and already stored in a Variable.
    • Max Loops - If the Process has loops and therefore the Timeout is triggered multiple times, Max Loops sets the limit how often the Timeout can be triggered before the Instance will fail. The loop counter will continuously count up until it reaches Max Loops and is not reset if the Form is delegated to another user. In other words, the loop counter is counted per Instance and not per User. Max Loops cannot be disabled. If you set it to zero or to a negative value, the complete Timeout is disabled.
    • Outcome - The Outcome to leave the Activity after a Timeout was triggered.
SETTINGS

Variable and delegation settings:

  • Variable type - Sets the Entity Type of the Variable backing this Form Activity. A specific Entity Type can be selected here, but it is also possible to not set a specific type by selecting (None). The behavior of the Variable type setting is always determined in conjunction with the Variable setting. All possible combinations are explained in the Variable setting description down below.
  • Clear attributes - Clears the listed Attributes in the Variable specified in Variable. Multiple Attributes can be entered separated by a comma , and a space .
  • Delegation filter user groups - A delegation of this Form is allowed to the Users Groups listed here. If no User Groups are set here and no Users are set below, the Form can be delegated to any User. If one or more Users and User Groups are set, the Form can only be delegated to the specified Users or User Groups. A User Group can be added by clicking Add. User Groups are entered by their name or ID. A User Group can be removed by clicking on .
  • Delegation filter users - A delegation of this Form is allowed to the Users listed here. If no Users are set here and no Users Groups are set approve, the Form can be delegated to any User. If one or more Users and User Groups are set, the Form can only be delegated to the specified Users or User Groups. A User can be added by clicking Add. Users are entered with their email address. A User can be removed by clicking on .
  • Delegation to variable - If the Form is delegated, the User to whom the form is delegated is stored in this Variable. If an Entity Variable is used, it has to be of Entity Type User. This field must not be empty, if delegation is enabled.
  • Delegation from variable - If the Form is delegated, the User delegating the Form is stored in this Variable. If an Entity Variable is used, it has to be of Entity Type User. This field must not be empty, if delegation is enabled.
  • Variable - Name of the Entity or Context Variable backing this Form Activity. The Form Activity loads values from the Attributes of the configured Variable when entering and stores values if exiting by either Save or Sign and Save Actions. No data will be modified when exiting by a Discard Action. When exiting with a Sign Actions, only the Signature is stored but no nothing else. How the Form Activity interacts with the Variable is configured in conjunction with the Variable type setting:

The following two rules apply regardless of the Variable and Entity Type configuration:
The content of hidden Form Controls is stored in the configured Variable The content of disabled Form Controls is not stored in the configured Variable

In this article