REQ approvals not RITM approvals

sam28
Tera Contributor

Can anyone clarify the following please: 

I have created an Order Guide for new joiners that contains 6 catalog items.  I need to generate a single approval at the REQ level rather than generate 6 approvals at the RITM level.  

My approval engines settings for sc_req states: Workflows are managing approvals on this table. I have disabled the default 'Service Catalog Request' workflow (the one which auto approves if the req is <$1000) and have checked for any other workflows on the sc_req table and can find none. 

The option to change workflow engine settings is greyed out.  I have read that if there are no workflows on the table, then Approval Rules should apply to the REQ.  There seems to be the same default Approval Rule set (<$1000 then set to approve) but when I deactivate the default workflow (<$1000 then auto approve) the Approval rule doesn't run and I get a message to say the rule won't run because Approval Engines aren't configured on sc_req table. 

I'm finding this functionality very confusing and simply want to generate a single REQ level approval for an Order Guide that contains multiple items so that the RC manager can approve, then the RITM's can move to fulfillment.  

Can anyone help with this? 

6 REPLIES 6

sam28
Tera Contributor

So at the moment I'm using a workaround.  I am using the default <$1000 workflow to kick off the workflow process and have amended that so it sets state to 'requested' 

I then have a second workflow that has a condition of Assignment Group is x and have set up a business rule to set assignment group as x based on the word Trigger being entered in the 'Special Instructions' field at checkout. 

I would like to trigger the second workflow based on the 'Order Guide name' is x. 

A second requirement is to display two cascaded variable fields 'First Name' and 'Last Name' next to the REQ number in list view.  Again these need to come from the sc_req_item table to the sc_req table. These fields are manually updated by the requestor (hiring manager) for a new starter who doesn't exist in AD yet, so is neither the requestor or requested for field. Use case for this is when a hiring manager or department head needs to see open new joiner requests we need to be able to see the name of the new joiner displayed. 

To show first/last name in a list view based on the variables your users enter when ordering, you would probably need to add two custom fields to the Request table. Then they can be populated with the respective values based on some logic (e.g. a BR on after insert for the REQ which queries RITMs and grabs this info).

Regarding the workflow part, you could set the condition to "None" in your second workflow so that it does not automatically run and then run it from you rscript (e.g. the BR you mentioned) whenever your conditions evaluate to true.

Use the startFlow() API to trigger the WF from script. 

Another apprach would be to just modify the OOB WF for REQ, add a scripted Condition block which checks for the child RITM Order Guide field and if the value matches e.g. a sys_property with the Order Guide, use your custom approval path instead of the OOB one.

Both should work I think...