This is version 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 . It is not the current version, and thus it cannot be edited.

Back to current versionRestore this version

DEFINE WORKFLOW ACTIONS#

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.

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 enter. 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.

• Suspended - Indicates that the workflow action is complete, however it is temporarily inoperative.
• In Production - Indicates that the workflow action is complete and available for use.
• Cancelled - Indicates that the workflow action is not available for use.
• Under Construction - Indicates that the workflow action is being created and is not yet complete.

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

Action Directed to

This field stores values from a supplied lexicon and refers to the individual(s) to whom the workflow action is communicating. There are eight options to choose from: User, Employee, Manager, Business Contact, Candidate, Current Identity, Specific Identity and People List.

With respect to emails, it is important to have set up the email addresses 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 hook to the P2K_HR_EMPLOYMENTS table.

User	If this recipient type is used, ensure that the user has been set up properly in IMUS with the email address stated there (for workflow actions that are issuing emails). If the email address on the IMUS record is blank then IF there is a person filled in on the IMUS record the system will try to retrieve the email address from the "Employee".
Employee, Manager, Current Identity or Specific Identity	If one of these recipient types is used, then ensure that the email address is stated on the person's Prime assignment record (IEAS). When an email is issued and this recipient type is used, the system will go to the employee's IEAS screen and read the email address from there. If there is no email address on the employee's Prime assignment, the system will go to their Personal Information (IEPI) to retrieve the email address. If their IEPI record does not have an email address, no email will be sent.
Business Contact	If this recipient type is used, ensure that the contact has been set up on IECI with the email address stated there. It is important that the business contact have a contact type value of "Business Contact" for their IECI record in order to select the contact as the recipient type in the UserCalc.
Candidate	If this recipient type is used, ensure that the email address is stated on the candidate's profile record IRCA.
People List	If this recipient type is used; ensure that the email address is stated on the person's assignment record that the people list detail record points to. Again if no address is found on that assignment record, the person's information record will be checked for one.

Category

This is a user-defined field that uniquely identifies the category to which 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 indicates the type of media that is to be used to communicate the event action. There are several types of media to choose from.

Reports	Launches a report. When this value is used the report that is specified is launched automatically (i.e. USPA)
Forms	Launches an screen form (i.e. IEPI).
Oracle Discoverer	Creates a list of subjects that Discoverer could report on.
Message	Creates a task that is displayed on the Workflow Tasks Screen.
Email	Allows for emails to be issued from within the application.
ODBC	Creates a list of subjects that an ODBC link could merge from. When this event media type is used, a record is created with ties to the following views in the database: P2K_AM_VMWF_CONTACTS, P2K_AM_VMWF_IDENTITIES and P2K_AM_VMWF_USERS. These are views and the data within these can be reported on using Discoverer.

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.

Type Value for Field
Reports	Report Function Name
Forms	Form Function Name
Oracle Discoverer	Discoverer Report
Message	Leave blank
Email	From Email Address
ODBC	Leave blank

For Forms, the value stored in this field will be the name of the function you are referencing. For example, if the intent of the workflow action is to navigate to the IPRLU screen then the field should be set to "IPRLU".

For Emails, If this column is filled in, then that is what will be used as the From Email address when the WorkFlow log is sent as an email. If this is left blank it works as follows:

1. ) It will pick up the email address column for the User that created the workflow log.
2. ) If the email address on that user is blank it will then find check for the employee that that user is indicated to represent and use the email address from that employee.
3. ) If the from email address is still blank it will retrieve the email address for the P2K user.
4. ) If the from email address is still blank, the WF log will be canceled as noted in WF emails that can not be sent below.

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 specified.

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. For 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 you 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.

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#

The 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 such that 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 that 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 you then press OK to this message, the record is saved. If this message should appear take the SQL script you are entering in IMWA and execute it in SQLPlus to see if there are any errors. Once you have a clean SQL script, put this into the IMWA and then you will not receive the error messages previously noted.

To use a completion clause you only have one piece of information from the workflow log available to use and it MUST be used in the clause. That piece of information is the ID for the record that triggered the log to be written. For 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, you 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. For 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; you may not edit the data.

FieldName

Definition

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 canceled.

Assigned on

This field indicates the date on which the event action was assigned. For example, if a candidate applied for a posting on February 1st then the workflow action event was fired at that moment. Therefore, in our example this is the date that 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 on which the workflow action was completed.

Assigned To

This field corresponds to the recipient of the workflow action.

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.

There is no page called 'WF Emails That Cannot Be Sent'. Would you like to create it?