This page (revision-54) was last changed on 26-Nov-2021 10:22 by Kevin Higgs

This page was created on 26-Nov-2021 10:22 by Administrator

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note
54 26-Nov-2021 10:22 12 KB Kevin Higgs to previous
53 26-Nov-2021 10:22 12 KB Meg McFarland to previous | to last
52 26-Nov-2021 10:22 12 KB Meg McFarland to previous | to last
51 26-Nov-2021 10:22 12 KB Meg McFarland to previous | to last
50 26-Nov-2021 10:22 12 KB Meg McFarland to previous | to last
49 26-Nov-2021 10:22 12 KB Meg McFarland to previous | to last
48 26-Nov-2021 10:22 12 KB Meg McFarland to previous | to last
47 26-Nov-2021 10:22 12 KB Meg McFarland to previous | to last
46 26-Nov-2021 10:22 12 KB Meg McFarland to previous | to last
45 26-Nov-2021 10:22 12 KB Meg McFarland to previous | to last
44 26-Nov-2021 10:22 12 KB kparrott to previous | to last
43 26-Nov-2021 10:22 12 KB kparrott to previous | to last
42 26-Nov-2021 10:22 12 KB kparrott to previous | to last
41 26-Nov-2021 10:22 12 KB kparrott to previous | to last

Page References

Incoming links Outgoing links
IMWA
IMWA

Version management

Difference between version and

At line 1 added one line
[{TableOfContents }]
At line 3 removed 2 lines
[{TableOfContents }]
At line 9 changed one line
The data for IMWA is defined on the [P2K_AM_WORK_FLOW_ACTIONS] and [P2K_AM_WORK_FLOW_LOGS] tables.
The data for IMWA is defined on the [P2K_AM_WORK_FLOW_ACTIONS] and [P2K_AM_WORK_FLOW_LOGS] tables
At line 11 changed one line
;[Action|EVENT_CODE]: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.
;[Action|EVENT_CODE]: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.
At line 15 changed one line
%%information Only the workflow actions that have a status of 'In Production' are available to be added to [UserCalcs|USERCALC]. But once they are included in a UserCalc just changing their status will NOT stop them from being used.%% \\ \\
%%information Only the workflow actions that have a status of 'In Production' are available to be added to [UserCalcs|USERCALC]. But once they are included in a UserCalc just changing their status will NOT stop them from being used.%%
At line 17 changed one line
;[Triggered In Product|WORKFLOW PRODUCTS]:This field defines the table that contains the workflow triggers. See overview for list of tables available.
* ''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.
At line 19 changed one line
;[Action Directed to|EVENT_RECIPIENT_TYPE]: This field indicates to whom the workflow action is communicating.
;[Triggered In Product|WORKFLOW PRODUCTS]:This field specifies the table that contains workflow triggers. See overview for list of tables available.
At line 21 changed one line
%%information 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.%% \\ \\
;[Action Directed to|EVENT_RECIPIENT_TYPE]: 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.
At line 23 changed one line
For both 'Employee' and 'Manager' these can only be used from tables with a link to the [P2K_HR_EMPLOYMENTS] table.
%%information 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.%%
At line 25 changed one line
;[Category|EVENT_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.
For both 'Employee' and 'Manager' these can only be used from tables with a hook to the [P2K_HR_EMPLOYMENTS] table.
At line 27 removed one line
;[Type|EVENT_MEDIA]: 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.
At line 30 added 18 lines
|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|EVENT_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|EVENT_MEDIA]: 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|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|TABLES and 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|DISCOVERER].
At line 31 changed one line
;[Report Parm Set]: The LOV contains a list of all [parameter sets|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.
||Type Value || Field Value
|Reports | Report Function Name
|Forms | Form Function Name
|Oracle Discoverer | Discoverer Report
|Message | Leave blank
|Email | From Email Address
|ODBC | Leave blank
|Open Enrollment | Life or Work Event Type
At line 33 changed 2 lines
;[Process by RMWF with like Actions|EVENT_BATCHED]: 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.\\
%%warning Note: __Action Directed__ to ''Department Co-ordinator'' cannot be batched together.%% \\ \\
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".
At line 36 changed one line
;[Process Until Marked as Completed|RESPONSE_REQUIRED]: 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|CONTINUOUS WORKFLOW LOG EMAILS].
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:
#) It will pick up the email address column for the User that created the workflow log.
#) 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.
#) If the from email address is still blank it will retrieve the email address for the P2K user.
#) 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.
At line 67 added 6 lines
;Report Parm Set: The LOV contains a list of all [parameter sets|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|EVENT_BATCHED]: 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|RESPONSE_REQUIRED]: 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|NAGGING WORKFLOW LOG EMAILS].
At line 42 changed one line
This tab provides the user with the ability to enter an SQL select statement for the completion clause.
The tab provides the user with the ability to enter an SQL select statement for the completion clause.
At line 44 changed 2 lines
;[Text|EVENT_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. \\ \\%%information 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. \\ \\
;[Text|EVENT_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. %%information 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.
At line 54 changed one line
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. \\ \\
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.
At line 56 changed one line
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.
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.
At line 60 changed one line
Users cannot 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:
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:
At line 70 changed one line
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. \\ \\
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.
At line 72 changed one line
%%warning This tab is for viewing purposes only. Users cannot edit the data.%% \\ \\
%%warning This tab is for viewing purposes only; you may not edit the data.%%
At line 78 changed one line
* Cancelled - Indicates that the workflow action has been cancelled.
* Cancelled - Indicates that the workflow action has been canceled.
At line 80 changed one line
;[Assigned on|ACTION_ASSIGNED_DATE]: 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.
;[Assigned on|ACTION_ASSIGNED_DATE]: 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.
At line 82 changed 5 lines
;[Completed On|ACTION_COMPLETION_DATE]: Indicates the date the workflow action was completed.
;[Assigned To|DRV_RECIPIENT]: This field corresponds to the recipient of the workflow action. \\ \\
%%warning NOTE: Assigned To will not populate when the Action Directed to is set to a People List%% \\ \\
;[Completed On|ACTION_COMPLETION_DATE]: Indicates the date on which the workflow action was completed.
;[Assigned To|DRV_RECIPIENT]: This field corresponds to the recipient of the workflow action.
At line 88 changed 2 lines
;[Reference Info|ACTION_CONTEXT2]: 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.
;[Reference Info|ACTION_CONTEXT2]: 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.
At line 92 changed one line
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.
If an Workflow email cannot be sent because either a FROM or TO email address cannot be found or is invalid, the Workflow log will now be marked as 'Canceled' with the completed date filled in. This will prevent the system from repeatedly trying to process a workflow log that cannot be processed.
At line 94 removed one line
----
At line 96 removed 2 lines
!!Used In
The 'Used In' tab maintains a list of the User Calcs that this workflow is referenced in. \\
At line 99 removed one line
%%warning This tab is for viewing purposes only. Users cannot not edit the data.%%\\ \\
At line 101 changed 16 lines
;[User Calc|USER_CALC_CODE]: This field defines the user calc that the workflow is listed in
;[Description|DESCRIPTION]: This field is a more descriptive text that describes the user calc.
;[Status|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|USER_NAME]: This is the name of the user who currently owns the user calc.
;[Usage|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|USER_CALC_LINE]: This defines the line in user calc that the workflow is referenced in.
[{If var='loginstatus' contains 'authenticated'
At line 131 added 2 lines
![Discussion|Edit:Internal.IMWA]
[{InsertPage page='Internal.IMWA' default='Click to create a new discussion page'}]
At line 120 changed 22 lines
!!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|SEQUENCE]: This field defines the order in which the attachments are processed.
;[Description|DESCRIPTION]: This field is a more descriptive text that describes the attachment file.
;[Start Date|START_DATE]: This field defines the start date of when the attachment file will be available for the workflow.
;[End Date|END_DATE]: This field defines the end date for when the attachment file will no longer be available of the workflow.
;[Attached|ATTACHMENT]: 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|LENGTH]: This field identifies the size of the attached file.
;[Mime Type|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|Edit:Internal.IMWA]
[{InsertPage page='Internal.IMWA' default='Click to create a new notes page'}]
}]
This page (revision-54) was last changed on 26-Nov-2021 10:22 by Kevin HiggsTop