I'm trying to configure automated routing of our Risk request type - TFL_Project_Risk.
The TFL_Project_Risk will have a relationship to a specific Project request type, and on the Project, there will be a data field "Project Coordinator". (who will administer our risk mgt process)
When the risk is created, I want the risk to be automatically assigned to the "Project Coordinator".
Since the "Project Coordinator" is a field on the project, I'm looking for suggestions about how the TFL_Project_Risk can determine and set the "Assigned To" field to be the "Project Coordinator" from the project.
Hi John, You can create a rule in the Risk request type, As soon as you enter the project name, make a rule to populate the 'Project Coordinator' of the project inot 'Assigned To' of Risk project type.
Thanks, that's exactly what I've been thinking. However since this is a project risk, it should already have the project field populated. I'm trying to use the Risk -- Project reference to resolve to determine the information stored on the project.
I can see the reference stored in KTNA_REFERENCES, where there are two rows that represent the relationship,
select parameter1 from KNTA_REFERENCES where source_id = '100585'
Returns a reference o the Project_id, which does not have the detail data.
I'm sure I could go through the Project_ID to get to the Request_ID and then again throurh the Request_ID to get at the details and the data I want. ... Is there a better way?
Mahen is right...the default Risk header has a 'Project' field with the token KNTA_MASTER_PROJ_REF. What we do is use a rule to populate the Request ID (different from Project ID) for that project into a hidden field (P_PROJ_REQ_NO) on the Risk:
select prj.pfm_request_id, prj.project_name from pm_projects prj where prj.project_id = NVL('[REQ.P.KNTA_MASTER_PROJ_REF]',1)
Then you can easily refer to the related project's REQD tokens from the Risk workflow using a token like:
Thank you both... You are right and that helped. I had overlooked the Project ID field in the Risk (I've also been looking at this problem for other types of related requests)...
I like the approach of storing the REQD for the project in a hidden field - that way I can access the data using a token as opposed to using a rule to look up the data from kcrt_request_details as in the following rule sql:
PROJECT COORDINATOR RULE
select substr(RD.Parameter17 ,1,instr (RD.Parameter17 ||'#@#','#@#')-1) UserID, substr(RD.Visible_Parameter17 ,1,instr (RD.Visible_Parameter17 ||'#@#','#@#')-1) PC_Name from kcrt_request_details RD, kcrt_fg_pfm_project PJ where RD.request_id=PJ.request_id and prj_project_id= [REQ.P.KNTA_MASTER_PROJ_REF]
------ I was about to ask for suggestions about how to simplify the approach and you beat me to it.