Model Properties

The first step in creating a new Workflow model is setting the Workflow model properties, such as general information (model ID/description), triggering information (type/event), filtering criteria, and the Task List behavior.

General

The General tab provides basic information for the Workflow model. This information is critical as it identifies the business activity, whether the model is in an active state, and version control.

Name: Workflow model name field. This is the actual ID for the Workflow model that is stored in the Workflow model table (wf_model).

Description: Longer description of the model that is descriptive of its purpose.

Notes: Optional input to describe the purpose of the Workflow model. This field may contain a detailed description of what the model does, a change history for the model, or even a "to do" list of desired enhancements.

Status: Represents the status of the Workflow model. An inactive status results in the Workflow model being ignored by Data Processing Services and Workflow Services. Inactive should always be the status during the design phase of a Workflow model since the model may be saved at various points in time. Once the Workflow model is complete, the status should be changed to Active.

Version: The version of the Workflow model. It should always be set to 1 initially. Although that is not an enforced rule, doing so allows the user to have multiple versions of the same model as the model goes through modifications over its life cycle. Workflow Designer supports dynamic version control on Workflow models.

Label: The Label option is externally used for the purpose of CDD reporting. Selecting Accept or Proof provides action to CDD reporting.

Trigger

Trigger Type: A Workflow model trigger is the process in which a Workflow Instance is initiated as a result of an action (Create or Update) in a BusinessPlus mask, Web Form or a scheduled request. Based on the trigger type, menus for scheduling and other trigger types will become available. The below table shows the trigger types and their functionality.

Create Instance Var Records for Webform Fields: Check the box to enable this feature. It creates the instance VAR records from the web form field names.

The way things work without using this check box: A webform can have many fields (text, date fields, check boxes, drop downs, etc.). There is a corresponding WF model for the form that can either match a field in the DBCustom or Model Variable. For this setting, we will focus on models set up with Model Variables. If there are no variables defined in the model, the field values will not be available in the wf_instance_var table. When the webform enters the model it will build the internal data table (if DBCustom is used) or update each model variable listed in the model.

The problem: If you need to add some more fields to the web form, or want to change the ID of the fields on the form, it requires the workflow model to be updated to match. This is not too bad when there are only a handful of changes however, if you are making major changes or adding in new functions, this could easily require 10-30 new variables being added which is cumbersome and requires the model version to be increased.

This feature:

On the WF engine side - No longer requires workflow variables to be added to a model.
On the WF model side - An SQL query will read wf_instance_var data for the given model and wf_key and put them all in a container.

To learn more in-depth details about using this feature, refer to the Using “Create Instance Var Records for Webform Fields”.

Subsystem: Filter that repopulates the Table/Object field's drop-down list with only the specified tables.

Table/Object: This defines the model as being triggered by a specific event that occurs to the selected table on the BusinessPlus mask transaction.

Event: Defines the event for the table every time a record is updated on the selected mask. When this event occurs, a request for the processing of the information is passed to the Workflow Engine.

Filter Tables: Used for table event triggers. The Filter Table setting checks the table(s) that are to be included in the Workflow model and are triggered based on the user input. When a Workflow model loads information as the result of a request for processing, it loads the information in the record that actually triggered the Workflow model, along with information from related tables as they apply to the loaded record. However, not all information may be needed for some users. Table filtering allows only requested information to be loaded into the model. Select the Filter Tables button to display the Table Filters dialog. Check the Enable Table Filtering box to turn table filtering on; the loaded table becomes available for selection. Note that the parent table must be included for any table selected.

Filter Data: This option works similar to table filtering with the exception that in data filtering the BusinessPlus user can select the desired tables and fields to be included as triggers for the model. Workflow models are defined to trigger whenever a table event occurs, i.e., an insert, update or deletion of a record. This means whenever that particular event occurs to a record in the defined table, the Workflow model processes that record each and every time. Sometimes this is not desired if the change is minor and could result in unnecessary Workflow model processing, such as placing the information back onto a Task List. The user can avoid this by enabling data filtering. Once data filtering is enabled and the fields of interest are defined, the Workflow model will only process a set of information when one of those fields has changed. Select the Filter Data button to display the Data Filters dialog. Check the Enable Data Filtering box to turn data filtering on. Select each field where filtering is required; Workflow will ignore the fields that are not selected. When Workflow loads the information for the model, it compares it to the information from the last time the Workflow model was processed. If one of the selected fields changed, the Workflow model processes the information again. If none of the fields have changed, the request for processing is ignored.
The Select All function selects every field for each table. This effectively turns off data filtering because the user is configuring every field as a field of interest. Since something needs to be updated for the Workflow model to trigger, the user is guaranteed that the processing request will succeed.
The Ignore All function deselects every field for each table. At that point, if data filtering is enabled, the user must either deselect data filtering or select at least one field. Typically, the Ignore All function is selected with data filtering enabled and a field of interest selected. This allows the user to reset the fields without looking at every field that was previously selected, giving them a clean slate with which to start selecting.
When data filtering is turned on the following occurs:

The old record information is loaded along with the new record information.
Based on the fields defined in data filtering, if one field changed, processing continues.
If none of the fields of interest have changed, the Workflow Instance is updated, but processing does not continue.

Tasklist

The Tasklist tab provides options to sort, as well as display URL and Document links on the Task List dashboard component and BusinessPlus Mask Option menu.

Order By: This field supports up to three levels of sorting based on the information in the record for the table trigger that is passed to the Workflow Engine. Items are listed by their property name, as it exists in the BT20 record (for example, Status, Suffix, or Name). Each sort level is separated by a comma. When internal data loaded for processing, values from the record are stored in the Workflow model instance record (group1, group2, and group3) so that task list items can be retrieved and displayed in the correct order. When sorting is updated in an existing Workflow model, a new version should be created because existing model instance records will not contain the necessary information in the correct fields to sort properly.

Group Labels: Define up to three levels of grouping on the Task List page. Each group level must match up with its corresponding sort level from the Order By field. However, it is not mandatory to group each level that is sorted. The difference between sorting and grouping is that sorting merely sorts the Task List items, while Grouping takes the sort levels and breaks them up into groups on the Task List page so that approvals can be done collectively on the basis of a particular value.

URL: The URL field option is available when a Task List item requires a Web address link to redirect an edge application or a selected BusinessPlus mask.

Include Document Links: Used when the user has images and/or documents attached to the table trigger record and a link is required for the Task List on each document viewer. If any images are attached, they would also be provided in the Task List summary.

Workflow Tasklist URL structure: To update the workflow task list URL go to the Model Properties - Tasklist and update the URL.

The new structure is: %BASE%/uiscreens/[subsystem]/[screen]?Filter=UniqueKey%20eq%20%27%UNIQUEKEY%%27

Travel Reimbursement Webform : %BASE%/uiscreens/webforms/TravelReimbursement?Key=%KEY%

Vendor Request Webform: %BASE%/uiscreens/webforms/Vendor_Request?Key=%KEY%

Travel Advance Webform: %BASE%/uiscreens/webforms/TravelRequest?Key=%KEY%

Direct Reimbursement Webform: %BASE%/uiscreens/webforms/DirectReimbursement?Key=%KEY%

POUPPR: %BASE%/uiscreens/Purchasing/POUPPR?Filter=UniqueKey%20eq%20%27%UNIQUEKEY%%27

APOHININ: %BASE%/uiscreens/AccountsPayable/APOHININ?Filter=UniqueKey%20eq%20%27%UNIQUEKEY%%27

SIOEUB: %BASE%/uiscreens/StoresInventory/SIOEUB?Filter=UniqueKey%20eq%20%27%UNIQUEKEY%%27

Job

Process as Job: The Job tab start activity supports all Workflow models as a job type. This means that if a user selects a Workflow model type to run as a process job, a NU Master record and BusinessPlus Job number would be created. The additional job process selection assists users to track the jobs from start to finish.

Limit running jobs: Selecting the amount of running jobs presents a remedy when BusinessPlus users have several jobs to kick off simultaneously but Workflow only allows a few jobs to run at a time. By selecting the limit running jobs, a user is able to select the exact amount of jobs that should run and the remaining jobs would be canceled or set for wait until the current jobs are completed.

Mask: The selection of a particular mask in this section would apply to the model in which the transactions would be processed. This setting allows the security menu mask to be specified for the processed job. In order to request this job, a user must have security permissions enabled to use the specified mask, and that mask value must be defined within the security structure.

Maximum simultaneous: Sets the amount of jobs that should run simultaneously and not exceed the amount allowed in Workflow. If the maximum limit is reached, the next instance of the model will not be allowed to run.

When maximum reached: When the maximum simultaneous jobs are currently processing, the user can set a pending job to "wait" or "cancel." As each job completes, the next job is kicked off until all have been processed.

Wait: Set remaining jobs to a pending state until all other jobs have completed processing.

Cancel: Cancels the remaining pending jobs and only completes the maximum simultaneous jobs allowed.

Wait retry time: Subsequent requests are handled and set to wait based on the amount of time selected in the retry value. The retry attempts are processed by the Workflow engine, so the setting is also subject to the Workflow engine's sleep cycle. If no value is specified, a retry time of 60 seconds is utilized.

Task List Header

The Task List Header tab provides options to select table columns to display in the workflow task list header.