Process models
Process models are created and edited via the Process models area in yuuvis® RAD designer. Open processes are shown in the workspace.
The Drawing page view area is the main workspace. This is where activities are created and the procedure is established via transitions or start conditions.
Dunning and retention periods for activities can be established in the Time periods view area.
The Localization view area shows all localizable data for the Schema languages.
The Validation view area shows errors and warnings for the current model.
The properties of an open model are shown in the Properties area. Properties can be shown by category or alphabetically.
After you have made changes, save the model on the Process model context tab. It can be deployed in the target system with which a connection can be made via the context menu of the process model.
Process models are managed via yuuvis® RAD management-studio.
Properties of Process Models
General | |
---|---|
Technical name |
Unique name used in scripts. The characters '/' and '\' are not allowed for technical names. The technical name is not shown on the yuuvis® RAD client user interface. |
Name | Display name of a process. Can be localized. |
Icon | Icon for flagging processes and tasks in yuuvis® RAD client. The button opens a selection dialog that you can use to assign an icon to the object type. |
Description | It is shown in the actions menu in yuuvis® RAD client. Can be localized. |
Initiators | Users and roles that can start a process in yuuvis® RAD client. |
Process owners | Users and roles that can view the process flow in yuuvis® RAD client. |
Accept empty scope |
Enabled: The main activity continues to be executed even if no included activity meets the start condition. Disabled: The process is suspended if the start condition is not fulfilled. |
Parameters |
List of all parameters of the process model. Data fields that were not yet set as parameters when the process model was created can be added as parameters retroactively. Parameter type: Data fields can be set as input and/or output parameters when they are created:
The parameter type can be changed. If you delete a parameter, the parameter property of the data field is removed. Mandatory field: Parameters can be flagged as mandatory fields. Input parameters (as mandatory fields) require a value via the start form, a script, an operation, or another process. |
Start form |
Form shown before the technical start of a process. The ... button opens the start form designer. A start form can be designed in the same way as object type forms (see Designing Forms). All data fields set up as input parameters are available. The fields on forms can be set to read-only. Start forms and activity forms can be exported as a file and imported via the context menu of a form’s header using the Apply content from file function. You can toggle between the script view and the layout view in the form header. Sample script: scope.model.datenfeld.required = true The 'datafield' field is a mandatory field on the form. Data fields of the type 'Boolean' no longer have a neutral status as mandatory fields on forms. |
Show start form | Active: A start form with fields for input parameters is shown before the start of a process. The data is forwarded to the first activity at the start of the process. |
Subject |
The content of the subject for a process can be formatted as a template with variables. The process properties, data from the data fields (var:datafield) of the process model, and boilerplate texts (res:boilerplatetext) are available as variables. Can be localized. If you enter an opening curly bracket in the field, a drop-down list of available values opens. The title length can be limited by specifying the maximum field length in square brackets. Date and time are issued by default for calendar data. The date format (e.g., Example (notation): {projectname[15]}, activity {activityname} Example (returned value): Vacation request, activity: Check The date, time, and numbers can also be formatted. Example: {var:varLong,number,$###,###.00} |
Main object type |
Object type through which processes can be started if the Process start with main object option is activated. Without the main object type and this option, processes are started via the More actions area. |
Main object quantity | Number of objects of the main object type that can be filed in the record. |
Process start with main object |
Enabled: Processes can be started only with an object of the main type. |
Allow other object types | Enabled: Objects of any type can be added to the record. |
The title and description are shown for objects in the record for which participants do not have the object type right 'View' as they are configured for the object type but without a content preview. |
Data fields | |
---|---|
Model-wide data fields though which data is managed. Data fields set as model parameters can be used on forms. The data type of existing data fields can no longer be altered if processes have already be created. |
|
Name |
Unique technical name. References to data fields are case-sensitive. Data fields cannot end with the string _meta. |
Display name | Display name on forms. Can be localized. |
Description | Data field description. Can be localized. |
Data type |
Data type for the data field. Data types can be set up as lists or sets. Unlike lists, sets contain only one instance of a value and are not sorted. Lists are only available for scripts, not on forms. The ID data type can be assigned to the users/groups class via which the individual user or group IDs are managed. Object types can also be assigned, including abstract object types, cross-context object types, or any general types. The String data type can also be classified for e-mail and web addresses. A new e-mail can be opened via e-mail fields by entering 'as addressee'; this entry can be called up as URL in the browser via the web addresses. Classification as a dynamic list is used to provide a list of data for the data field for selection via scripts. Classification as an e-mail should only be used when all e-mail addresses are indexed using the same structure. If this is not the case, the hit lists in columns with e-mail addresses become confusing. |
Set up as model parameter |
Enabled: Data field is set as model parameter for forms. Model parameters have a name and the Input parameter and/or Output parameter type. This property can be modified via Parameters. |
Events | |
---|---|
List of all events to which a script can be assigned. On the server side, scripts are run when the event occurs. |
Resources | |
---|---|
User-defined data types |
List of all user-defined data types. User-defined data types can be used as the data type for data fields after they have been created. Types:
|
Boilerplate texts | Model-wide boilerplate texts can be used for subject lines, for example. Can be localized. |
Global script |
Model-wide script that provides functions for all the scripts of the model. Run on the server side. Here and for the form scripts, there are various editing features available to help you create the script in the ribbon on the Script context tab and in the context menu of the script area. In addition, IntelliSense is available as scripting support. Open IntelliSense using the keyboard shortcut Ctrl+Space. The Manage scripts functional right is required. |
Logging | |
---|---|
List of process activities. Enabled: Messages are logged for the activity. You can also enter additional texts here. These texts cannot be localized. |