Workflow does not create a Human Task when that Task's Expiry is set to be in the past; but workflow still requires it to proceed

[Berto2002]

I have a Human Task that is set to expire when the Scheduled End Date of the Change Request is reached. The BP then should assess if no answer has been given and should move-on to the next step for a Change Manager review.

This is a screenshot of the executed BP on a test Request which is awaiting the completion of the "Implementer: Start the Implementation":

This is a shot of the CR itself which shows the BP did not create the Human Task it states it is waiting for (no Activities). So the CR is stuck and cannot move forward even though my BP provides a case for a Scheduled Date being passed (review and re-schedule).

The issue appears to be created when the Scheduled End Date is already in the past. This seems to fail to create the Human Task rather then creating it and immediately expiring it. In short, the BP and the back-end of Service Manager app are not congruent. Although our teams are usually not silly enough to schedule something for the past - and we usually spot it in review - it is possible that it can happen and I think this is a bit of a flaw in the system: to allow it to break CRs right at the end of the process.

 

 

[Guest Mary]

Hi @Berto2002

22 minutes ago, Berto2002 said:

This seems to fail to create the Human Task rather then creating it and immediately expiring it.

Your screenshot shows an expired activity - can you confirm what is displayed here? 

Expired tasks are displayed in expired tasks under the Activities section.

It seems you have provided 6 minutes between the above request being logged (09:38 on 28/06/2021) and the request reaching the node with the human task which expires at the scheduled end date and time  (09:44 on 28/06/2021).

From your screenshot, the request got to the human task at  (09:46 on 28/06/2021). Hence the task was created but had expired at the point of creation. 

 

 

[Berto2002]

Hi Mary. Thanks for pointing that out. Yes, the task does appear in the Expired list, as below screenshot.

So, the issue is that the Expiry of that task (presumably immediately after creation) has not triggered the BP to move on as it should (via the Decision with "No Match" route as above) to the "Email End of Change Window" node. However, this BP does move on in that manner when the Expiry occurs when the "Implementer: Start Implementation" task is already created.

To cater for this case, I think I need to put-in additional node before that Task that checks the Expiry and if it's already passed, go straight to the Email node. Unless @Mary you know of another way to ensure this does not fail for this reason?

[Guest Mary]

@Berto2002

I'd suggest preceding the human task with two extra nodes

• Cloud> Utilities> Get (current)Timestamp node 
• Decision node  - this checks the current time stamp (when the request reaches that node) against the scheduled end date on the request
  • If the current time stamp value is less than the scheduled end date time stamp, the human task is created and you can set the expiry date as the scheduled end date.
  • If the current timestamp is greater than the timestamp of the scheduled end date, define what you would like to happen next on your process e.g. proceed to email node.

[Berto2002]

Thank you, I will see what I can do with this suggestion.

However, do you also see that there is no need for this failure to be the case if only Service Manager would acknowledge the Expired Task and act as if it had expired while created?

[Guest Mary]

@Berto2002

2 hours ago, Berto2002 said:

do you also see that there is no need for this failure to be the case if only Service Manager would acknowledge the Expired Task and act as if it had expired while created

The expired task is being treated as defined. It can be viewed as 

1. Create the human task

2. Wait for change in the outcome of the human task

3. Proceed based on the new value in the outcome field

This particular request is stuck on step 2 because there isn't a change to the value in the outcome field which on creation is set to expired instead of blank because of the expiry date you have populated on creation (step 1). 

Hope this clarifies the  behaviour. 

 

 

 

 

 

[Berto2002]

Hi @Mary, the solution does not seem to be working. Can you please see if you can spot the flaw here?

Symptom: Scheduled End Date set for 16:45 thus:

When I ran the workflow, it followed the route below because the green Human Task task was the first it hit. Thus, it went down the route that the Current Date > the End Date

The Expression in that decision is this:

But you can see that the "Email End of Change Window" node was triggered at 16:21 which is 4 minutes before the End Date so the condition above should not have been met.

Diagnosis

I start by getting the latest information in case the Scheduled Start and End dates have changed

I use cloud automation to clean-up the date format

I use cloud automation ( as suggested above) to get the current date and time.

But that has an Operator Parameter that forces me to select Add or Subtract. I don't know what they do and I cannot find anything on the Wiki when I search for Cloud Automation Utilities and their explanations.

In short, it looks like the expression I have should work but it doesn't so what needs to change please? What does the Add/Subtract do? 

Thanks in advance

Berto

 

[Guest Mary]

Hi @Berto2002

The timestamps for the scheduled end date and current timestamp are required. These values should be evaluated in the custom expression above (i.e. you should be comparing values from two cloud automation nodes )

The Add/Subtract determines what calculation you want carried out on the starting timestamp e.g. return value for 3 days prior to startingtimestamp or 3 days after startingtimestamp.  In this case, you can set the value to Add and leave the time units blank

Clicking on the help/info icon below provides more details.

 

 

 

[Berto2002]

@Mary OK I shall try the following:

 

[Berto2002]

Hi @Marythis did not work.

My Task Expiry was 10.55:

I completed the step prior to the time checks at 11:10 which is > current date/time. You can see how it then went on to create the Start Implementation task

The workflow went to the green box which was set with the formula that it must only go there if current date/time < the scheduled End Date (comparing the two cloud automations). It should have gone the other way because now I am again stuck with an Expired task that I cannot complete and the workflow is still waiting for it.

Please help me through this and what to do next to get an accurate time comparison for this purpose.

Thank you

Berto

[Steve Giller]

@Berto2002 Are you taking Daylight Savings into account?

My understanding of a Timestamp is that it will always be in UTC (GMT+0) where the date output can be formatted and may well be in BST (GMT+1)
You can test this without changing anything by ensuring the difference is always greater than an hour.

[Berto2002]

@Steve Giller.

 

	Scheduled End	Time of action
UI time	10.55	11.10
GMT	9.55	10.10

I understood Mary's suggestion was to compare the output from two cloud automations to ensure the timezone is consistent. But think what you're saying is that the two cloud automations could be using different timezones. The only case, using the above data, where "Cloud Automations->Getcurrent date time->timestamp" IS LESS THAN "Cloud Automations->Set Scheduled End date time format->date" is if the time I took the action in the UI (11.10 BST) is interpreted in GMT (10.10 GMT) but the Scheduled End is interpreted in BST (i.e. 10.10 , 10.55). But my experience is that the Cloud automation to Set the Date Format returns in GMT because the output of that node is used directly in the Notice node that follows and it displays in GMT on my UI as below.

Formatter:

Then the Notice uses this expression: "Scheduled Change Window is from: &[global["FormattedStart"]["date"]] to &[global["FormattedEnd"]["date"]]." and we get this:

So what node/setting do I need to change to align these nodes to use the same timezones for the purposes of this comparison/decision, please?

Regards,

Berto

 

[Guest Mary]

Hi @Berto2002

Could you confirm each cloud automation node in your process has a unique Result Reference? 

[Berto2002]

Morning @Mary

I believe they do:

[Guest Mary]

 

Hi @Berto2002

The scheduled end date timestamp is missing from your process hence you are not getting the expected result. The decision nodes should evaluate 

• Task should not be created if Current timestamp> Scheduled end date timestamp 
• Task created if Current timestamp< Scheduled end date timestamp 

 

The cloud automation node should be configured as 

Note that the Starting time stamp on the Get Scheduled end date timestamp is the scheduled date value from the get req details Hornbill Automation node.

The decision node evaluates the expression 

[Berto2002]

@Mary. It works. Thank you very much for getting me there.