Toggle menu

Workflow - Message Action

Messages can be sent by form submissions to the workflow engine and be caught by intermediate and boundary message events.

When sending a message you must be able to identify the process instance you are sending the message to (generally that means you need to know the business key). That means that this field cannot be used in a stand-alone form to send messages because, without additional work, there is no way for the field to know which process instance to send the message to.

This field is used when building cancellation into workflow models that are used with the Self Service and User Requests products. When interacting with a process using these products the instance to send the message to is held in the WORKFLOWPROCESSID context variable and picked up automatically by this field type. The special GOSS_StarterCancel message reference is also used.

For more information about messages and cancellation see the Messages and Signals and Building Cancellation into your Workflow Models reference articles.

Properties

LabelDescriptionType Name
Message ReferenceA unique identifier for the message.

The GOSS_StarterCancel message is used by the Self Service template to trigger the cancellation of a running process instance. The process design must have a Boundary Message Event configured to detect this message. The name property of this Boundary Message Event must correspond to the name of the form used to perform the cancel
MESSAGEREFERENCE
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
Success messageThe text to display when the task completes successfullySUCCESSMESSAGE
Failure messageThe text to display if the workflow fails to startFAILUREMESSAGE
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 for the corresponding workflow process. 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.

When a form includes a workflow action, the fields on the form are included as process variables for the corresponding workflow process. If this property is set to true, non-storing 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
EXCLUDENONSTORINGFIELDS
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 examples. Note that this function updates process variables, nothing elseVARIABLESFUNC
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"
KEEPFILEREFERENCES
Record HistoryIf true, a history will be created for the workflow and a history event will be recorded when the form is submittedRECORDHISTORY
EventA short one or two word phrase that describes the event. If no value is supplied the string "Form Submission" will be used.

The value of another field can be used by adding the field's 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. If no value is supplied form's description will be used.

The value of another field can be used by adding the field's name between # characters
EVENTDESCRIPTION
Event User RoleName of the role the user was performing as when they triggered the event. For example, "customer".

The value of another field can be used by adding the field's name between # characters
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.

The value of another field can be used by adding the field's name between # characters
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 along with the 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
Update Self-service SummaryGenerate a new self service summary event for this history. See History Events and Summary Events for more information about summary eventsUPDATESUMMARY
Reporting FieldsSelect one or more fields to generate/update a "reporting" history. This is an additional history created alongside the standard history, with a labelc value of "reporting". You can write a reporting history even if the main "Record History" property is set as false

Pick the fields whose values you'd like to store in the history. Do not pick any fields that may contain personally identifiable information - otherwise you'll invalidate the whole point of creating a "reporting" history. See the reference Labelc Histories and Reporting Data article for our conventions and below for an example
REPORTINGFIELDS
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
Sop 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
DocumentationAdd documentation to your field to help explain any complex functionality to future users. You might include information on what the field does and how it relates to other fields on the form. Notes added here are only ever visible in the Forms Designer, they can be searched for, viewed and downloaded from the action panel. See Common Field Properties for an exampleDOCUMENTATION

Action Results

The following can be accessed using .utilGetActionResults once the action has been processed.

"FIELDNAME": {
    "success": "true"
}

"FIELDNAME_CONF": {
    "MESSAGE": "Message sent successfully",
    "success": "true"
}

Adding Additional History Properties

Rather than providing static values in the forms designer for subject and event properties, you can instead build them programmatically. To add additional properties to an event or 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.getFieldValue('PRICE')) * parseInt(helper.getFieldValue('QUANTITY'));
    return additionalProps;
}

Additional Event Properties

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)
  • private (note that this must be a boolean, not a string, so the value of another field cannot be used directly)

For example, to override a description with the value of a field:

function(helper) {
    var additionalProps = {};
    additionalProps.description = helper.getFieldValue("TEXT1");
    return additionalProps;
}

Or to dynamically set the privacy setting of the event:

Workflow History Privacy Setting

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

Data Types

Form fields always submit their values back to the server as strings, which means the values of your process variables will also be strings. Take care when manipulating process variables server-side or updating the values of fields using .setFieldValue - the values you set should also be strings.

Having said that, it is possible to create and pass JavaScript objects to a workflow process using the prefix js_. Variables with this prefix will remain as objects in the workflow engine.

For example, this function would create two new variables. js_objectExample would behave as an object if you used it in a workflow script activity:

function(helper, processVars) {
    processVars.new = "test";
    processVars.js_objectExample = {
        "key": "value"
    };
    return processVars;
}

js_objectExample

See Creating and Updating Process Variables in the workflow knowledge base for more information.

Last modified on 2 January 2024

Share this page

Facebook icon Twitter icon email icon

Print

print icon