Toggle menu

Workflow - Start Action (version 1)

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

LabelDescriptionType Name
Process DefinitionThe 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 charactersProtects against workflow property injection by replacing the special characters { } and # with * when the values of fields are set as workflow process variablesREPLACESPECIALCHARACTERS
LabelThe 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 LabelWhether the label for this field will be visible on the form. Set to false to hide the field's labelSHOWLABEL
Always show fieldWhether 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 aliasesALWAYSSHOW
Save form data as objectThis 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 messageThe 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 messageThe text to display if the workflow fails to startFAILUREMESSAGE
Ineligible failure messageThe 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 fieldsExclude 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 fieldsExclude non-storing fields from the submitted process variables, in the same way as read-only fields described aboveEXCLUDENONSTORINGFIELDS
Process variables functionA 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 examplesVARIABLESFUNC
Keep file referencesControls 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 NameThe form that will be used to display summary data for this workflow. Defaults to the name of the start form if not suppliedSUMMARYFORMNAME
Record HistoryIf 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 historyRECORDHISTORY
Create Self-service SummaryGenerate 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 DescriptionThis 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 instanceSUBJECTDESCRIPTION
Subject Additional PropertiesOptional. 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
EventA 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 "#EMAILADDR#". This must be the complete field name when an external type definition is used. This can be obtained by hovering the mouse over the required field
EVENTEVENT
Event DescriptionA 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 #PROCESSNAME#, #PROCESSDESCRIPTION#, #BUSINESSKEY# and #STARTFORMDESCRIPTION# are also available
EVENTDESCRIPTION
Event User RoleName 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 PrivateIf 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 PropertiesOptional. 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 DataIf 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 summarySTOREFORMDATA
Form NameIf 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 suppliedFORMNAME
Debug modeWhether 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 messageDEBUG
History Label AIf 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 changedLABELA
History Label BIf 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 changedLABELB
History Label C-EThe properties for labels c, d and e are hidden and not used by defaultLABELC, LBAELD, LABELE
Stop Processing on ErrorIf 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 informationSTOPPROCESSINGONERROR

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 #PROCESSID# and #BUSINESSKEY#.

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 _STARTED.

"FIELDNAME_STARTED": {
    "processId": "90211",
    "businessKey": "2063-5248-5212-6230"
}

You could access this variable in the DATA function of the email action field:

Email Action Data Function
 

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:

PDF Table
 

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:

Additional Event Properties
  

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:

Remove Process Variable
 

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;
}

Add Process Variables
 

Last modified on January 20, 2022

Share this page

Facebook icon Twitter icon email icon

Print

print icon