Wiki: IMWA

This is version . It is not the current version, and thus it cannot be edited.

Back to current version Restore this version

DEFINE WORKFLOW ACTIONS#

DEFINE WORKFLOW ACTIONS
Completion Clause
Workflow Logs
Workflow Emails That Cannot Be Sent
Used In
Attachments
Notes

A workflow action is the result of a key event. Some key events can include a salary/wage increase or hiring/terminating an employee. These events require specific actions to occur, thereby driving the workflow process.

The workflow event action is defined in the Define Workflow Actions (IMWA) screen.

The data for IMWA is defined on the P2K_AM_WORK_FLOW_ACTIONS and P2K_AM_WORK_FLOW_LOGS tables.

Action: Action is a user-defined code that uniquely identifies the workflow action item. Action is tied to the database column Event_Code which is a 16 character alphanumeric mandatory field that must be manually entered. It is through the event code that the workflow action is referenced in a workflow UserCalc.

Status: This field defines the status of the workflow action. The four options available from the lexicon are: Under Construction, Suspended, In Production or Cancelled.

Only the workflow actions that have a status of 'In Production' are available to be added to UserCalcs. But once they are included in a UserCalc just changing their status will NOT stop them from being used.

Triggered In Product: This field defines the table that contains the workflow triggers. See overview for list of tables available.

Action Directed to: This field indicates to whom the workflow action is communicating.

With respect to emails, it is important to have the email addresses set up on the appropriate screens in order for the system to use the address when issuing the email.

For both 'Employee' and 'Manager' these can only be used from tables with a link to the P2K_HR_EMPLOYMENTS table.

Category: This is a user-defined field that uniquely identifies the category the workflow action belongs. This field is for information purposes only and has no functionality behind it. There is only one supplied option (Not Specified) to select from, however, users can create new lexicon values accordingly.

Type: This field defines the type of media that is to be used to communicate the event action. There are several types of media to choose from.

Type Reference: The type used depicts what type of value needs to be entered here. For example, if the type is set to "Reports" then the value to be entered here must be the function name of the report to be run.

Report Parm Set: The LOV contains a list of all parameter sets that were created. For example, if the type is set to Reports, the report is for USPA, and a user has created a specific parameter set for USPA, then that parameter set can be defined.

Process by RMWF with like Actions: If this toggle is checked, the workflow action event is batched and will only be sent when the RMWF process is run. Example: in order to prevent a user from being bombarded with emails each time a workflow action occurs, this toggle is turned on so that the emails are sent to the user only once, when the RMWF process is run. This allows users to run the process at a specific time. The workflow action items are sent only once after this process is run. This toggle is used only with Emails or Reports types.

Note: Action Directed to Department Co-ordinator cannot be batched together.

Process Until Marked as Completed: This toggle can be used in conjunction with the toggle above and a completion clause to keep sending an email out every time the RMWF is run until the completion clause is satisfied. See section below on Nagging Workflow Log Emails.

Description: This field provides a brief description outlining the intention of the workflow action. Although it is not a mandatory field, we recommend you always provide a brief description for the purpose of clarity. If the Type for this workflow action is "Email", then the value stored in this field will be seen in the "Subject" line of the email. Description is a 50 character alphanumeric field.

Completion Clause#

This tab provides the user with the ability to enter an SQL select statement for the completion clause.

Text: A completion clause is required in order to close the workflow loop. An SQL select statement can be entered here, if the value in the select statement is returned, the workflow action is complete. If no value is returned, then the workflow action item remains incomplete.

Note: The value is arbitrary BUT must be only one single value (or column).

The exceptions to this are found in the example of an email being sent. In this case, no completion clause is provided, yet the workflow action is marked with a status of 'Completed' or in the case of just wanting to launch a form or report.

SQL statements can be difficult to write therefore we recommend that a person with SQL knowledge along with familiarity of the various tables within the database be responsible for writing these statements.

When entering a 'Completion Clause' on IMWA, if the SQL script is invalid or has error the following message will be shown:

"Event Text Error = ORA-00942: table or view does not exist
ORA-06512: at P2k.P2k_SMREFCUR", line 8"

If a user presses OK to this message, the record is saved. If this message appears, users should copy the SQL script that is being entering in IMWA and execute it in SQLPlus to see if there are any errors.

Once you have a clean SQL script, copy it into IMWA. Users should not receive the error messages previously noted.

To use a completion clause, users only have the ID for the record that triggered the log to be written. This ID MUST be used in the clause. Example: A completion clause for WF_RAP would need to use ":RAP_ID" in the completion clause.

SELECT 1 FROM P2K_RE_APPLICATIONS WHERE ID = :RAP_ID AND APPLICATION_STATUS = '80'

Due to changes in the Oracle9i Database, users can no longer specify "*" as the value in the select, as in SELECT * FROM. The value selected is arbitrary and not used for anything so it can be a column or a constant value BUT can only be a single value. Example:

SELECT 1 FROM …

will work in every completion clause.

Workflow Logs#

The 'Logs' tab maintains a history of the workflow actions and also provides the user the ability to view the workflow action in more detail.

An important note to remember is that every time a workflow action event takes place, a log is created. Therefore, reviewing the 'Logs' tab will indicate how many times the action event was fired. It is also a good place to review for testing purposes to ensure that the workflow action actually took place.

This tab is for viewing purposes only. Users cannot edit the data.

Status: This field defines the status of the workflow action. The four options available from the lexicon are:

Newly Entered - Indicates that the workflow action has been assigned but has not yet been completed.
Completed - Indicates that the workflow action has been completed.
Pending - Indicates that the workflow action is still waiting to be completed.
Cancelled - Indicates that the workflow action has been cancelled.

Assigned on: This field indicates the date the event action was assigned. Example: If a candidate applied for a posting on February 1st, then the workflow action event was fired on February 1st. Therefore, February 1st will populate this field.

Due On: This field refers to the date that the workflow action will appear to the recipient either on their task list or email, etc.

Completed On: Indicates the date the workflow action was completed.

Assigned To: This field corresponds to the recipient of the workflow action.

NOTE: Assigned To will not populate when the Action Directed to is set to a People List

Additional Info: This field corresponds to the information stored in the 'Description' section of the UserCalc.

Reference Info: The information in this field is hard coded into the program. It is created and controlled by the application developers and not by the user. It was coded into the program to provide the user with the ability to look up certain basic information.

If the workflow is for sending emails, then the address(es) it was sent to will be added to the bottom of the Reference Info after it has been sent.

Workflow Emails That Cannot Be Sent#

If a Workflow email cannot be sent because either a FROM or TO email address cannot be found or is invalid, the Workflow log will be marked as 'Cancelled' with the completed date filled in. This prevents the system from repeatedly trying to process a workflow log that cannot be processed.

Used In#

The 'Used In' tab maintains a list of the User Calcs that this workflow is referenced in.
This tab is for viewing purposes only. Users cannot not edit the data.

User Calc: This field defines the user calc that the workflow is listed in

Description: This field is a more descriptive text that describes the user calc.

Status: This field identifies the status of the user calc. Values are:

00: Under Construction – the user calc has not been completed and therefore will not be published
10: Pre-compiled
20: Being Tested
30: To Be Published – The user calc is ready to be published
40: In Production – The user calc has been published and is in use
99: Compiling

User: This is the name of the user who currently owns the user calc.

Usage: This field defines how the user calc is to be used in the application. Values are:

00: Not Specified
01: Disbursement Message – The user calc will be executed for each disbursement record when UPDISB is run.
02: Secondary WF - This selection is used for workflow user calcs which will not be fired from the trigger directly and must be called from another user calc.
03: Pro-Active WF – The user calc will be executed when UMPWF is run.

Line: This defines the line in user calc that the workflow is referenced in.

Attachments#

The 'Attachments' tab is used to maintain the names of the files (attachments) that are linked to the workflow. The attachments can be entered with a Start and End date, which will allow the files to be picked up only during this timeframe.

Multiple attachments can be sent on a single workflow email. Note that some email servers will limit file sizes and may limit the total amount that can be sent out.

The Length and Mime Type columns can be left blank when the file is attached to the table. These two fields will be filled in by the application as needed.

With the addition of the new tab contents for an attachment, the use in a workflow email does not change. The workflow is built in the same manner as normal, the Description on the Act line is still the body of the email.

Seq: This field defines the order in which the attachments are processed.

Description: This field is a more descriptive text that describes the attachment file.

Start Date: This field defines the start date of when the attachment file will be available for the workflow.

End Date: This field defines the end date for when the attachment file will no longer be available of the workflow.

Attached: This field holds the name of the file that is to be attached to the workflow. The file can be added or removed from this field as needed.

Length: This field identifies the size of the attached file.

Mime Type: This field is used to identify the data type of the attached file. Example: The mime type can be a docx, txt, pdf, jpg, etc.

Notes #

Click to create a new notes page