This field has been replaced by the Workflow - Start Action field
This field starts an instance of the selected workflow process when the form page is submitted. Values from the form are passed to the workflow engine as process variables named after the fields that hold those values. The variables can be manipulated using the process variables function. Information returned from the workflow engine can also be displayed to the user.
If used via iCM from a Form App Shortcut on the iCM homepage, the action field can be set to be displayed, presenting the user with a drop-down list of their site user aliases. The user can select an alias and the action will start a workflow as the selected site user when the form is submitted. This functionality can be enabled for forms displayed on the site, but as site users will only ever have one identity, it would serve no purpose.
Properties
Label | Description | Type Name |
---|---|---|
Process Definition | The name of the process to start an instance of. You can pick a full workflow ID (a specific version to start) or the workflow key (which will always start the latest version) | WFNAME |
Replace special characters | Protects against workflow property injection by replacing the special characters | REPLACESPECIALCHARACTERS |
Label | The label to show if the field is visible. The field will be visible if more than one site user alias has been supplied in the SITEUSERALIASES property in the user context variable, or if ALWAYSSHOW is true | LABEL |
Show Label | Whether the label for this field will be visible on the form. Set to false to hide the field's label | SHOWLABEL |
Always show field | Whether the field should be always visible, even if only a single choice of site user is available. Setting this property to true means that the field will be shown even when there are not two or more aliases to choose from. This property should generally be false. It is only useful if working in iCM from a Form App Shortcut and your iCM user has multiple site user aliases | ALWAYSSHOW |
Save form data as object | This feature is not normally used or needed, we don't recommend using it as it results in the same data being stored in multiple places. Whether the workflow variables should be saved to an iCM form data object. If true, an iCM form data object will be used to store a copy of the workflow variables. The canonical workflow variables remain in the workflow engine. When this setting is used the workflow start form must be single page or use an external type, and all task forms must have the same type as the start form. | SAVEOBJECT |
Success message | The text to display when workflow starts successfully. Simple field value substitution is supported using hashes. #PROCESSID#, #BUSINESSKEY# are special tokens that will return the processID set in the modeller and the ID of the instance that started. #BUSINESSKEY# is often returned to the user as a reference number | SUCCESSMESSAGE |
Failure message | The text to display if the workflow fails to start | FAILUREMESSAGE |
Ineligible failure message | The text that will be displayed if the current site user is not eligible to start the process. When working in iCM using Form App Shortcuts, if the current iCM user has no site user alias they will be ineligible to start the workflow process | INELIGIBLEFAILUREMESSAGE |
Exclude read-only fields | Exclude read-only fields from the submitted process variables. When a form includes a workflow action, the fields on the form are included as process variables in the corresponding workflow process instance. If this property is set to true, read-only fields will not be included. This setting can be useful when you want to display some information on a workflow form that you don't want to be included in the resulting process instance | EXCLUDEREADONLYFIELDS |
Exclude non-storing fields | Exclude non-storing fields from the submitted process variables, in the same way as read-only fields described above | EXCLUDENONSTORINGFIELDS |
Process variables function | A server-side JavaScript function that can manipulate the process variables generated by the form before the workflow action is performed. This is most commonly used to dynamically create process variables. The function is executed server-side only. See below for some examples | VARIABLESFUNC |
Keep file references | Controls whether or not the workflow retains references to any uploaded files. When a workflow form is rendered using the Forms Service and the form includes upload fields, the workflow process instance will, by default, retain references to any uploaded files so that they remain available to the workflow process for as long as it is running. If the same workflow form is submitted twice, the default behaviour is to release the reference to the file that was uploaded first. If both files should remain accessible to the workflow, select the "Keep references (add to existing)" setting for this field. If you don't want the workflow to keep any file references (so they will only be available when processing the initial workflow action when the form is submitted) select "Don't keep references" See File Uploads and Email Attachments in Workflow for more information | KEEPFILEREFERENCES |
Summary Form Name | The form that will be used to display summary data for this workflow. Defaults to the name of the start form if not supplied | SUMMARYFORMNAME |
Record History | If true, a history will be created for the workflow and a history event will be recorded when the form is submitted. If this property is not enabled the workflow will not record any history | RECORDHISTORY |
Create Self-service Summary | Generate a summary history event that may be used by the Self Service and User Requests products. For more information about summary events, see History Events and Summary Events. Summaries are only generated if "Record History" is enabled. The options for when summaries are generated are: start and end, start only, end only, none at all. Summaries may still be generated and added to the history by other user tasks in the workflow process. Summaries include a copy of the form data, including references to uploaded files in the file store | CREATESUMMARY |
Subject Description | This hidden property sets the subject data when the history for this workflow instance is written. By default it includes the description, processDefinitionId and processDefinitionKey set in the workflow modeller, plus the userId (the username) of the user that started this instance | SUBJECTDESCRIPTION |
Subject Additional Properties | Optional. A function that can be used to either add new properties to or override existing properties within the history subject. To add additional properties, return a JSON object from this function. To override existing properties, return a JSON object that includes one or more elements with the same name as an existing property. See Adding and Overriding Properties below | SUBJECTADDITIONALPROPERTIES |
Event | A short one or two word phrase that describes the event. This property is required if you are recording history. You can use the value of a form field by adding the field name between # characters, eg " | EVENTEVENT |
Event Description | A more detailed human readable description of the event, required if you are recording history. You can use the value of a form field as you can for event. The tokens | EVENTDESCRIPTION |
Event User Role | Name of the role the user was performing as when they triggered the event. For example, "customer". You can use the value of a form field as you can for event | EVENTUSERROLE |
Event Private | If true, this event will be marked as private. The Self Service and User Requests products contain configuration options that can show or hide private events. You can use the value of a form field as you can for event | EVENTPRIVATE |
Event Additional Properties | Optional. A function that can be used to either add new properties to or overwrite existing properties within the event object. To add additional properties, return a JSON object from this function. To override existing properties, return a JSON object that includes one or more elements with the same name as an existing property. See Adding and Overriding Properties below | EVENTADDITIONALPROPERTIES |
Store Form Data | If true, data submitted with the form will be stored in the history event. A form could later be populated with this data and displayed to the user as a summary | STOREFORMDATA |
Form Name | If Store Form Data is true, this is the name of the form that will be used to display the data. Defaults to the name of the current form if not supplied | FORMNAME |
Debug mode | Whether to enable debug mode for this field. This is automatically enabled if the form debug panel is displayed. Set to true to display the actual error reported from the Workflow Worker instead of the standard failure message | DEBUG |
History Label A | If Record History is set as true the name of the process started by this field will be recorded as the value of labela. This property is hidden and should not be changed | LABELA |
History Label B | If Record History is set as true the business key of the instance started by this field will be recorded as the value of labelb. This property is hidden and should not be changed | LABELB |
History Label C-E | The properties for labels c, d and e are hidden and not used by default | LABELC, LBAELD, LABELE |
Stop Processing on Error | If true, and an error is encountered, further action fields on the form won't be processed. See The Form Lifecycle: Control and Action Processing for more information | STOPPROCESSINGONERROR |
Action Results
The following can be accessed using .utilGetActionResults once the action has been processed.
"FIELDNAME": {
"processInstanceId": "130477",
"businessKey": "9824-8513-6759-4348",
"success": "true"
}
"FIELDNAME_CONF": {
"MESSAGE": "The process was started successfully, your reference is 9824-8513-6759-4348",
"success": "true"
}
When the start action completes successfully the process ID and business key can be accessed in the "success message" displayed to the user using
The process ID and business key are also returned to the form in a helper variable, which could be accessed in any server-side actions placed after the workflow start action in your form. This variable is made up of the field name suffixed by
"FIELDNAME_STARTED": {
"processId": "90211",
"businessKey": "2063-5248-5212-6230"
}
You could access this variable in the DATA function of the email action field:
And then added to the email body or PDF:
<table class="icmformdatapagetable">
<tbody>
<tr>
<td colspan="2" class="icmformdatacontainer">Label</td>
</tr>
<tr>
<td class="icmformdatalabel">Text 1</td>
<td class="icmformdatavalue">{{FORMDATA.PAGE1.0.[TEXT1] }}</td>
</tr>
<tr>
<td class="icmformdatalabel">Your Reference</td>
<td class="icmformdatavalue">{{DATA.businessKey}}</td>
</tr>
</tbody>
</table>
Which would generate:
Adding Additional Properties
Rather than providing static values in the forms designer for subject and event properties, you can build them programmatically instead. To add additional properties to an event or to the history subject, return a JSON object from the subject/event additional properties functions:
function(helper) {
var additionalProps = {};
additionalProps.additionalPropertyKey = "additionalPropertyValue";
additionalProps.totalCost = parseInt(helper.queryFieldValue("PRICE")) * parseInt(helper.queryFieldValue("QUANTITY"));
return additionalProps;
}
Overriding Properties
To override an existing property, include a property with the same name in your JSON object. The following property names can be overridden:
Subject Properties:
- description
- userId
- proxyUserId
Event Properties:
- event (the event name)
- description
- userRole
- userId
- proxyUserId
- historyDescription (used in SUMMARY events)
For example, to override a description with the value of a field:
function(helper) {
var additionalProps = {};
additionalProps.description = helper.queryFieldValue("TEXT1");
return additionalProps;
}
Manipulating Process Variables
By default the fields and values submitted with your form are passed to the workflow engine as process variables. The process variables function lets you manipulate the variables that are created.
For example, the following will remove a specific process variable from the map:
You can also create process variables. This example is taken from the GOSS Contribute product:
function(helper, processVars) {
processVars.CONFIGNAME = "contributeevent";
// Additional tasks
processVars.ADDITIONALTASKS = [{
"form": "CONTRIBUTE",
"name": "Contribute Event"
}, {
"form": "PRICES",
"name": "Default Prices"
}];
return processVars;
}