TRIGGER

Another kind of branch is TRIGGER, which can appear in a ManualStep Workflow Step or an ActivityStep Workflow Step. It also has a To field and an optional embedded Gosu block. However, instead of a condition checking to see if a certain Gosu attribute is true, someone or something must manually invoke a TRIGGER from outside the workflow infrastructure. (Typically, this happens from either PolicyCenter interface or from a Gosu call.) Guidewire requires a branch ID field on all TRIGGER elements, as outside code uses the ID to manually reference the branch.

Unlike all other the IDs used in workflows, TRIGGER IDs are not plain strings but typelist values from the extendable WorkflowTriggerKey typelist. This provides necessary type safety, as scripting invokes triggers by ID. However, it also means that you must add new typecodes to the typelist if you create new trigger IDs.

Invoking a trigger

How does one actually invoke a TRIGGER? Almost anything can do so, from Gosu rules and classes to the PolicyCenter interface. Typically, in PolicyCenter, you invoke a trigger though the action of toolbar buttons in a wizard. This is done through a call to the invokeTrigger method on Workflow instances. (As it is also a scriptable method, you can call it from Gosu rules and the application PCF pages.) See Synchronicity, transactions, and errors for a discussion of the invokeTrigger method and its parameters.

Internally, the method works by updating the (read-only) database field triggerInvoked on Workflow to save the ID. (See the PolicyCenter Data Dictionary entry on Workflow.)

PolicyCenter then wakes up the workflow instance and the TRIGGER inspects the triggerInvoked field to see if something invoked the trigger. Depending on how you set the invokeTrigger method parameters, the workflow handles the result of the TRIGGER either synchronously or asynchronously.

Creating a trigger branch

To access the TRIGGER branch dialog, right-click the starting step and select New Trigger from the menu. (Studio only displays those choices that are appropriate for that step.) This dialog contains the following fields:

Field	Description
Branch ID	Name of this branch as defined in the WorkflowTriggerKey typelist. Select from the drop-down list.
From	Automatically generated. Workflow step ID of the beginning point of the branch.
To	Workflow step ID of the ending point of the branch.

After you create the branch, click on the link (line) that runs between the two steps. You see the following fields, which are identical to those used to define a GO branch:

Field	Description
Branch ID	Automatically generated.
From	Automatically generated. Workflow step ID of the beginning point of the branch.
To	Workflow step ID of the ending point of the branch.
Arrow Visible	Show an arrow head on the branch line to indicate direction.
Description	Description of this branch.
Condition	Must evaluate to either `true` or `false`.
Execution	Gosu code to execute if the workflow takes this branch.

Trigger availability

Simply because you define a TRIGGER on a ManualStep does not mean it is necessarily available. You can restrict trigger availability in the following different ways:

You can specify user access permission through the use of the Permission field.
You can add any number of Available conditions on the Available tab to further restrict availability. If the condition expression evaluates to true, the trigger is available. Otherwise, it is unavailable.
For example (from PolicyCenter), the following Gosu code indicates that the workflow can only take this branch if a user has permission to rescind a policy. (The condition evaluates to true.)
```
PolicyPeriod.CancellationProcess.canRescind().Okay
```