Skipping Activity Sets Based on Parent Case Information

[Jim Coyne]

Once the request is approved by a manager, we have 3 different sets of documents that must be accepted by the employee, but only 1 applies for each case depending on data on that specific case (based on answers in the Record Producer).  We want to skip the other 2 that do not apply to that specific case.

I have an advanced Trigger script setup that checks that the approval Activity set is completed by the manager AND checks to see if the data matches what is required for the documents and it is working. However, how do you tell the Activity set to skip because it is not actually required based on the data on the case?  That is where we are stuck at the moment.  They just sit there waiting.

Unless I'm mistaken, I can't really use Audiences because they do not look at a specific Case in order to return true or false.  And we can't really do it via scripting because we don't have any link to the parent case, do we?  It was originally setup to use an Audience and it queried the open cases, but there could be multiple cases, which is causing the employee to get multiple docs to sign/accept.

Again, if I'm not mistaken, I need the condition on the Activity Set itself (context is linked to the case) and not the individual Activities (linked to User).

[Beno_t Proulx]

Could you possibly accomplish a similar result another way, like a scheduled job that would look at the "co-dependant" activity sets contexts for each case and update the status of that context to "skipped" for those that are still running or awaiting if any of them is finished?

Something like: (just did this quickly, surely could be improved to me more efficient or generic. sorry for the lack of clarify)

(function() {
  
  
  var dictAll = {};
  var dependantActivitySets = ["9b6beb5e1b678050dab2db1dcd4bcbfb","5bad2b9e1b678050dab2db1dcd4bcb62","a92d639e1b678050dab2db1dcd4bcb40"];
  
    var gr = new GlideRecord('sn_hr_le_activity_set_context');
   //Get All co-dependant activity Sets contexts not finished/error/skipped/cancelled 
 
   gr.addEncodedQuery('activity_setIN' + dependantActivitySets.join(",") + '^stateINawaiting_trigger,running_activities^NQ');
    //gr.setLimit(100);
    //gr.setWorkflow(false);
    //gr.autoSysFields(false);
    gr.query();
  
    gs.print(gr.getRowCount());
  
    while (gr.next()) {
      
      //Add to dictionnary the Case SysId and number of time of of the Activity Set context came up
      if (gs.nil(dictAll[gr.hr_case.toString()])) {
        dictAll[gr.hr_case.toString()] = 1;
      } else
      {
      	dictAll[gr.hr_case.toString()] = dictAll[gr.hr_case.toString()] + 1;//gr.getUniqueValue();
      }
      
    }
  gs.print(JSON.stringify(dictAll));
  
  //Iterate in the dictionary for each case, and find those that have less than the number of activity set contexts that are co-dependant, which would mean one of them was closed/finished/cancelled/skipped
  
  for(var key in dictAll) {
  	var value = dictAll[key];
		if (value < dependantActivitySets.length) {
       var gr2 = new GlideRecord('sn_hr_le_activity_set_context');
      gr2.addEncodedQuery("hr_case=" + key + "^activity_setIN' + dependantActivitySets.join(",") + '^stateINawaiting_trigger,running_activities^NQ");
      gr2.setValue("state", "skipped");
      gr2.update();
    }
  // do something with "key" and "value" variables
	}	
  
})();

[JV2]

Activity Set triggers are quite rigid when it comes to offering options. You basically have to work around those capabilities.

Still, there are a few options you have, depending on how much you want to achieve, and what your client wants.

I had a similar case with a client. The scenario was:

• You have Activity Set A, starting with the HR case.
• Activity Set B1 and B2 come after A. And, just one of those supposed to be triggered (they are exclusive, based on data/fields entered in the HR case).
• Activity Set C, will start once either Activity Set B1 "or" Activity Set B2 is completed.

First, I had the Activity Set C with a trigger condition as Advanced. And I set up the code to return true if either B1 or B2 was completed.

Both B1 and B2 are part of the Lifecycle event, and both will appear on the top workflow when the HR case starts.

After A is completed, the conditions for B1 and B2 are evaluated (trigger condition is Advance, and the code on both guarantee that only one will match the condition).

Let's say that B1 matches the condition. At this moment, B1 tasks are triggered, while B2 Activity Set remains as "awaiting trigger" (the condition will never match). When all activities under B1 are completed, C is triggered because its condition was either B1 or B2 were completed.

At this moment, you will see A completed, B1 completed, B2 still "awaiting trigger", and C triggered. The workflow has moved forward.

If it were the B2 condition the one triggered, that means B1 will remain as "awaiting trigger" and when B2 is completed, C will be triggered (state = running activities).

The above approach actually works. It's in Production and everyone understand how the case flows.

BUT,

If you say that you don't want to have that B1 or B2 with condition "awaiting trigger" for ever, you could have a BR on the Activity Set Context table, set in a way that if B1 (or B2) is set to Finished, it should look for the B2 (or B1) associated context and set it as Cancelled.

Note that if you set the context to "Skipped" instead, the whole activity set is removed from the flow displayed on top of the HR case, which could be confusing (the activity set was at first, but not anymore). This could be (or not) what you need. I personally prefer to see the activity set cancelled.

The flow would look like this:

The above approach is just one option. But it's worked and my client is happy (thus I'm happy).

Hope this help.

[Rahul Singh6]

Hi, Thank you for your inputs to the question. I also tried the same and it working for me.

However, I few of my Activity Sets which were skipped based on advanced trigger and stay in the "Awaiting Trigger" status eventually change their status to "Error" and a few of them into "Cancelled" state. 

The Error state for an activity set is alarming and though harmless, may not sit well with the client.

What could be the possible cause of this "Awaiting Trigger" status to "Error" change? Is it due to customized interval (I have kept the activity set interval timer to 1 to 5 minutes) to speed up testing. OR "Activity set inputs" or "Max activity count"?

[Kalyani35]

Hi,

I have a similar requirement and have implemented same solution just instead of setting state to Cancelled I am setting state of Activity set context to Skipped. My observation is that the workflow - HR Activity Set Trigger Check still keeps running and stuck on the activity to evaluate the trigger condition. Did you encounter this ? What happens to that running workflow? Does it keeps evaluating?

Thanks!