Screen
Description
This step is used to define a custom form that will be usually used by a end-user, to approve or reject a task.
Step Tabs
Here you could find the list of available Tabs for the Screen Step for each Process type. You could browse to the corresponding page to view more information.
&&TODO&&
| USER MANAGEMENT | PERMISSION MANAGEMENT | ACCOUNT RESERVATION | |
| Task details | |||
| Fields | |||
| User queries | Does not apply N/A | Does not apply N/A | Does not apply N/A |
| Triggers | |||
| Incoming transitions | |||
| Outgoing transitions |
Task details
- Task name: identified name for the task that will be created when the workflow is request.
- Actor(s) expression: allows you to write an expression to identify the actor depending on the requested role. One can use EL expressions (*) based on role and application attributes. For instance: SOFFID_MANAGER/${primaryGroup}
- Assignment script: alternatively, allows you to write a Beanshell script to return the actor depending on the process variables. For instance: return primaryGroup.attributes{"owner"};
- Approve from email: checked it to allows you to send a mail for approval the task. &&TODO&& Indicar como se configure el server para envio de mails?
Fields
In this tab, you could choose what fields the process form will show to the end users. You can choose these fields from all identity attributes, and from the attributes defined for the workflow on the Attributes Tab. By default, all the identity attributes will be shown. You can choose the fields you want to show, add new fields, and delete the fields that do not need to generate a task. Also, you can sort the fields, you only need to do drag and drop on the Order column.
For each field you may indicate if it is a readOnly field, and you may add Validation script and Visibility script. The validation script allows you to define rules, the field has to comply with these rules. The visibility script allows you to define the rules to show or hide a field.
Trigger
Incoming transitions