PROCESS WORKFLOW

Application Overview

T24 Process Workflow is aimed at grouping various businesses and banking procedures into a
logical process of activities. This grouping enables allocation of work to different users, ensuring
vital tasks are left out causing a breakdown or delay in the process chain.
Individual activities are defined at micro level defining rules, statuses and user groups, which can
all be reused. These activities are then set out in a pre-defined sequence allowing a customized
business processed to be followed.

This module does not carry any business functionality but can be used to define and tune the flow of
business supported by other T24 modules.

Application Design

AUTO.ID.START

Figure 1 – AUTO.ID.START

An AUTO.ID.START record must be set up for the PW.PROCESS and PW.ACTIVITY.TXN tables,
with an ID format of the following:
For PW.PROCESS table – ‘PW’YYJJJnnnnn. Where YY = Year, JJJ = Julian date and nnnnn =
sequence number.

For PW.ACTIVITY.TXN, the setup is the same but for the prefix of ‘PA’. – ‘PA’YYJJJnnnnn.

Once the AUTO.ID.START record has been committed and authorised a LOCKING record will be
created for FBNK.PW.PROCESS and FBNK.PW.ACTIVITY.TXN containing the start Id’s for
each file.

If these records are not set up correctly, when launching a new PW.PROCESS record in T24
Browser, a blank screen will be displayed.

To correct this, reset the LOCKING records by correcting and recommitting the AUTO.ID.START
record for PW. The Cache file for Browser, F.OS.XML.CACHE, will also need to be cleared of all
records pertaining to PW.PROCESS.

LOCKING

Figure 2 - LOCKING

LOCKING records for FBNK.PW.PROCESS and FBNK.PW.ACTIVITY.TXN will be

automatically created once the AUTO.ID.START record for PW has been committed and authorised.
COMPANY

Figure 3 - COMPANY

The PW.PROCESS table (only) must be entered into the PGM.AUTOM.ID field on the COMPANY
record to enable automatic creation of ID’s.
PW.STATUS

Figure 4 – PW.STATUS

Status codes are defined separately and attached to PW.ACTIVITY records. They are needed to
define the default status or starting status of an activity (DEF.STATUS.CODE on the
PW.ACTIVITY record) e.g.. PENDING, and are also used to set the STATUS.CODES, in
conjunction with a STATUS.RULE, on the PW.ACTIVITY record when the conditions of the rule
has been met.
PW.PARTICIPANT

Figure 5 – PW.PARTICIPANT

This table is used to group Users or Account Officers together and is attached to either the
PW.ACTIVITY or PW.PROCESS record. A User/Account Officer is then automatically allocated to
an Activity, spreading the workload systematically between all users/ Account Officers within the
PW.PARTICIPANT group.

This helps Users/Account Officers in identifying their daily work by using an Enquiry to drill down
and launch their specific tasks.
PW.TRANSITION

Figure 6 – PW.TRANSITION

Transition rules are attached to activities via the PW.ACTIVITY or the PW.PROCESS.DEFINITION
table. These rules determine when the status of an activity changes and the status further determines
if and when a subsequent activity can appear on the TO.DO list for a user and hence be executed.
PW.MAPPING

Figure 7 – PW.MAPPING

These records are used to map data from one activity record to another. The Mapping ID is attached
to the PW.ACTIVITY record where the data is to be mapped to. EG. If in a process a CUSTOMER
record is created, then an ACCOUNT record for that customer and you wish to map certain data
from the customer record to the account record, the PW.MAPPING record will be attached to the
PW.ACTIVITY for the account activity.

Please refer to the Data Mapping Worked Example for further information.
PW.MAP.SOURCE

Figure 8 – PW.MAP.SOURCE

This table can be used to define common field links to map data to be attached to the
PW.MAPPING table. This table allows data links to be re-used.

Please refer to the Data Mapping Worked Example for further information.
PW.ACTIVITY

Figure 9 – PW.ACTIVITY

These records determine the status, transition rules, duration, data mapping and so on of an activity.
The TARGET field defines which T24 application will be launched when the activity is executed; it
details how the application will be run i.e. how the application is usually executed from the
command line. The TARGET can also be an EB.DYN.ACTIVITY or EB.TABLE.DEFINITION. See
the EB.DYN.ACTIVITY user guide on how to create user defined tables within T24.

Please refer to the Data Mapping Worked Example for further information.
PW.PROCESS.DEFINITION

Figure 10 – PW.PROCESS.DEFINITION

This table allows the linking of activities together in a logical business flow. It defines when an
activity is enabled depending on pre-required Activities and their Statuses or Transition Rules. So
PW.PROCESS.DEFINITION helps not only in defining the activities to be a part of the process, but
the sequence and the stage at which they have to appear in the process.

ENQUIRY

Launching of activities takes place through a drilldown ENQUIRY of the PW.ACTIVITY.TXN file,
allowing a user to automatically launch the activities from the enquiry.

A basic PROCESS.STATUS and TO.DO ENQUIRY comes as part of the T24 PW module.

Specified key words in these enquiries allows Process Workflow to function and care must be taken
to not delete or change vital fields in the basic ENQUIRY, PROCESS.STATUS.
See the below example of the important fields involved.
A FIELD.NAME field on the ENQUIRY record, as in the above example, must contain the data ‘PW’,
along with the FIELD.DISPLAY being set to ‘PWACTIVITY’.

And an ENQUIRY.NAME field on the ENQUIRY must contain the launch functions as in the above
example.
If the ENQUIRY is not set up correctly intermittent problems will occur, with activity status’s and
PW.ACTIVITY.TXN records not being updated, and mapping not working.
PW.PROCESS

Figure 11 – PW.PROCESS

The first step in setting up and starting a process is by creating a PW.PROCESS record. This
contains the PW.PROCESS.DEFINITION record that defines and determines the flow of activities
to be executed.

Once the PW.PROCESS record has been committed in Authorise mode, for each activity set up on
the PW.PROCESS.DEFINITION record that has no PRE.REQ.ACT attached to it, a
PW.ACTIVITY.TXN record will be automatically generated, thus only allowing activities to be
executed once previous tasks or activities have been performed. These PW.ACTIVITY.TXN record
IDs along with some detail are written to the PW.PROCESS record.
ENQUIRY

Figure 12 – Enquiry Process Workflow status

Now that the process has been created, running the ENQUIRY, PROCESS.STATUS displays all
activities and their statuses that can be or have been executed. Drilldown on the enquiry will allow
the chosen activity to be executed automatically.
 Figure 13 – Enquiry PROCESS ACTIVITY TXN

The standard TO.DO ENQUIRY allows activities to be listed per user, which allows a specific user to
concentrate on their allocated tasks.
PW.ACTIVITY.TXN

Figure 14 – PW.ACTIVITY.TXN

This file contains the records of all activities that can be or have been executed. Once an activity
has been executed the TRANSACTION.REF field contains the ID of the record of the T24 or
EB.DYN.ACTIVITY application that was executed.

Upon completion of an activity, the system scans through the PW.PROCESS.DEFINTION record
and creates PW.ACTIVITY.TXN records for all activities that could be started if their PRE.REQ.STAT
has been met.

PW.ACTIVITY.TXN Id’s are automatically generated by the system (as long as the AUTO.ID.START
record has been set up, see ‘Setting Up of the System’ document for PW), these records cannot be
created manually.
Data Mapping Worked Example

Taking into account that the PW.VERB, PW.OBJECT, PW.PARTICIPANT, PW.STATUS and
PW.TRANSITION records have been created.

In the following example we will be mapping data from an ACCOUNT application to a

FUNDS.TRANSFER application.

Two PW.ACTIVITY records are created; one to launch an Account application; the other to launch a
Funds Transfer application.

Figure 1 – PW.ACTIVITY Record

Figure 2 – PW.ACTIVITY Record

A PW.MAPPING record is created, this will detail where the data is to be extracted from and where
it is going to.

TABLE.TO details what type of T24 application this record is going to be attached to, in this case it
is an FT application.
DATA.NAME any description can be chosen so long as it matches it’s corresponding field
TARGET.VALUE.
DATA.SOURCE : This field dictates what data is being mapped and where it is coming from. In this
case the field CURRENCY in the PW.ACTIVTY record CREATE.ACCOUNT.
TARGET.FIELD is the data is being mapped to, this field must exist in the application detailed in the
TABLE.TO field, in this case FUNDS.TRANSFER.

Figure 3 – PW.MAPPING Record

The PW.MAPPING record is attached to the appropriate PW.ACTIVITY record in the MAPPING.ID
field.

Figure 4 – MAPPING.ID Field

A PW.PROCESS.DEFINITION is created with the two PW.ACTVITY ’s listed.

 Figure 5 – PW.PROCESS Definition

A new PW.PROCESS is created.

Figure 6 – PW.PROCESS Definition

A composite screen with the ENQUIRY PROCESS.STATUS is launched.

The PW serial numbers are the PW.PROCESS ID.

The PA serial numbers are the PW.ACTIVITY.TXN ID

We can see that the Account Activity is first in the launch list.

Figure 7 – Account Activity

The CREATE.ACCOUNT launches an ACCOUNT record that is populated and committed, note
the currency is CHF.

Figure 8 – Account Record

Once the Account record is committed and the Enquiry refreshed, the CREATE.ACCOUNT
activity has the committed record’s ID displayed.

Figure 9 – CREATE.ACCOUNT activity

The CREATE.FT activity is activated and launches a FT application.

On launch of this record the Currency type is mapped from the Account activity to the
DEBIT.CURRENCY field, the record may now be populated and committed.

Figure 10 – FT Record (Debit Currency field)