Common step elements

It is possible for each step in the workflow to also contain some or all of the following:

The PolicyCenter Administration tab displays the current step for each given workflow instance.

Enter and exit scripts in workflows

A workflow step can have any amount of Gosu code in the Enter and Exit blocks to define what to do within that step. (Enter scripts are far more common.) To access the enter and exit scripts block, select a workflow step and view the Properties tab at the bottom of the screen.

Enter Script

Gosu code that the workflow runs just after it evaluates any Asserts in Workflows (conditions) on the step. (That is, if none of the asserts evaluate to false. If this happens, the workflow does not run this step.)

Exit Script

Gosu code that the workflow runs as the final action on leaving this step.

For example, you could enter the following Gosu code for the enter script:

var msg = "Workflow " + Workflow.DisplayName + "started at " + Workflow.EnteredStep
print(msg)
Note: If you rename a property or method, or change a method signature, and a workflow references that property or method in a Gosu field, PolicyCenter throws a ParseResultsException. This is the intended behavior. You must reload the workflow engine to correct the error (Internal Tools > Reload > Reload Workflow Engine).

Asserts in workflows

A step can have any number of Assert condition statements. An Assert executes just before the Enter block. If an Assert fails, the workflow throws an exception and handles it like any other kind of runtime exception. To access the Assert tab, select a workflow step.

Condition

Each condition must evaluate to a Boolean value.

Error message

If a condition evaluates to false, then the workflow logs the supplied error message.

For example, you could add the following assert condition and error message to log if the assertion fails:

Condition

  Workflow.currentAction == “start”

Error message to log if assertion fails

  “Some error message if condition is false”

Events in workflows

A step can have any number of Event elements associated with it. An Event runs right after the Enter block, and generates an event with the given name and the business object. To access the Events tab, select a workflow step.

Entity Name

Entity on which to generate the event. This must be a valid symbol name.

See also:

Event Name

Name of the event to generate. This must be a valid event name.

See also:

For example:

Entity Name

account

Event Name

someEvent

Notifications in workflows

A step can have any number of non-blocking Notification activities. A notification in workflow terms is an activity that PolicyCenter sends out, but which does not block the workflow from continuing. PolicyCenter only uses it to notify you of something. The workflow generates any notifications immediately after it executes the Enter code, if any. See ActivityStep workflow step for more information on activity generation.

Name

Name of the activity.

Pattern

Activity pattern code. This must be a valid activity pattern as defined through Guidewire PolicyCenter.

Init

Optional Gosu code that the workflow executes immediately after it creates the activity. Typically, you use this code to assign the activity. If you do not explicitly assign the activity, the workflow auto-assigns the activity.

For example:

Name

notification

Pattern

general_reminder

Branch IDs in workflows

A branch is a transition from one step to another. Every branch has an ID, which is its reference name. An ID is necessary because the Workflow instance sometimes needs to persist to the database which branch it is trying to execute. (This can happen, for example, if an error occurs in the branch and the workflow drops into the Error state). A branch ID must be unique within a given step.

Generally, as you enter information in a dialog to define a step, you also need to enter branch information as well.