Changing BR: Cascade Request Approval to Request Item

[Bill_Collins]

I am trying to understand this business rule and if it can be changed to cascade a "Requested" approval state to Request Items. Thank you for the advice.

var gr = new GlideRecord("sc_req_item");
gr.addQuery("request", current.sys_id);
gr.query();

while(gr.next()) {

if (!gr.cat_item.delivery_plan.nil())
startPlanApproval(gr);
else if (gr.cat_item.workflow && !gr.cat_item.workflow.nil())
startFlowApproval(gr);
else continue;

gr.update();
}

function startFlowApproval(gr) {
gr.approval = 'requested';
if (gr.stage == "waiting_for_approval" && current.approval == "approved")
gr.stage = 'Request Approved';
else if (current.approval == 'rejected')
gr.stage = 'Request Cancelled';
}

function startPlanApproval(gr) {
gr.approval = current.approval;
if (gr.stage == "waiting_for_approval" && current.approval == "approved")
gr.stage = getStageFromPlan(gr); // move them away from waiting for approval
else if (current.approval == 'rejected')
gr.stage = 'Request Cancelled';
}


function getStageFromPlan(reqitem) {
var nextStage = "nothing";
var planID = Packages.com.glideapp.servicecatalog.DeliveryPlan.resolvePlanID(reqitem);
// return the first delivery task
var gr = new GlideRecord("sc_cat_item_delivery_task");
gr.addQuery("delivery_plan", planID);
gr.orderBy("order");
gr.query();
if(gr.next())
nextStage = gr.name.getDisplayValue();

return nextStage;
}

[RobWoodbyrne]

Bill, This is kind of vague...

Can you provide some detail about the requirement and what the behavior is doing, verse what is expected?

[Bill_Collins]

Sure thing.

Requirement: A Request contains one or more Request Items. The Request has an approval which is requested and subsequently approved. The children (Request Items) are then put into a "Requested" approval state sending the appropriate approval requests. When the Request Item approvals have been made the Request Item delivery plan kicks off. When All Request Item tasks have been closed or rejected, the Request is closed. We will accept Closed or Closed Incomplete.

My business rule modification: It appears this afore [sic?] mentioned business rule cascades approval down from the Requests to the Request Items. I want to modify the business rule to put the children Request Items into a "request" state rather than an "approved" state. The approver will come from an approval rule.

Bill

[RobWoodbyrne]

Ahh, OK.. I can understand that! 🙂

I don't know how to do that through modifying a business rule, I'll leave that up to the bigger brains (You can tell them by their propeller hats, *cough* John Roberts, Mark Stanger *cough*) but I think this relates to trying to get the Request to auto approve, then have the individual items get 'stuck' in a 'Somebody needs to approve this individual item' state, where the other items in that request (Order guide) can move on.

It turns out that I originally thought you had to use the 'simple' approval engine to use inline Approval tasks on Execution Plans. This is not the case, so make sure you have 'Advanced' approval engine (or Process Guides) turned on for Service Catalog tasks. Then, add an 'Approval Task' as the first task in the Execution Plan. This should give you the functionality that I think you are looking for.

Let me know if I am completely off course here.

[Mark Stanger]

There's probably a way to do this, but you need to be very careful whenever you're modifying these Service catalog-related business rules because there's a ton of execution plan/workflow logic tied into them. The typical approach I've used when dealing with a scenario like this is to go ahead and let the Request approval cascade down to the items. You would then set up a secondary in-line approval within each item that needed it by creating an approval task within the execution plan. This task could be the very first task in the execution plan attached to the item so that no work got done for the item request unless the approval took place first. Using this approach, there would be no need for item-specific approval rules or process guides.