Logic question: Does "Expression matched: [true]" in Log mean it should go the direction of that Expression?

[Berto2002]

We've had a flow do something unexpected: A Request for a VIP Customer should have had their ticket flagged as VIP but it didn't.

The "Expression matched: [true]" log implies to me that it should have gone the direction where the Expression is listed ("yes" in the flow below). But it actually went the direction of the "No Match" option.

Am I reading this incorrectly?

The expression is this: It's looking for a match of VIP in the Organisations:

And the User has this configured. This approach typically works.

[Victor]

5 minutes ago, Berto2002 said:

The "Expression matched: [true]" log implies to me that it should have gone the direction where the Expression is listed ("yes" in the flow below)

Not quite. 

The "Expression matched: [true]" you see in the logs means that there was a match for an "expression" in any of the existing branches of the decision node. A "No Match" branch is also an expression which can generate an "expression match" log entry. Best to not look at the ""Expression matched" entry not from a custom expression but a generic expression (which includes the standard "No Match")

[Berto2002]

Hi Victor. OK but what you are telling me is that the Log File does not give me the reasons the workflow choice was made (i.e. which of the two expressions matched or why), only 1) there was no error and 2) the outcome. It seems there is room for improvement/enhancement in the detail of this log file. It would be better to clarify which expression was matched such as 1) "Expression [label for the Expression] matched: [true]" or 2) "No Match: [true]" or perhaps 3) "Tasks: Approved: [true]" to help diagnosis.

In this case, I consider that my Expression is faulty in some way so I can progress with this knowledge, thank you for clarifying.

[Steve Giller]

@Berto2002 Where are you pulling that output from? It doesn't appear to be in the format that I'd expect to see.

[Guest Mary]

@Berto2002

Please review the expression.  You do not have an organisation called VIP,  so Organisational Group One ==VIP will not return a match and neither will any of the other org groups. This is why the outcome is  no match. 

The expression should be Organisational Group One== VIP Users or Organisational Group One contains VIP Users

 

 

[Berto2002]

35 minutes ago, Steve Giller said:

@Berto2002 Where are you pulling that output from? It doesn't appear to be in the format that I'd expect to see.

Hi Steve, this content is me pasting the log file output from VelocITy into a Teams chat. It rather nicely automatically put it in a nice table :-)

[Berto2002]

18 minutes ago, Mary said:

@Berto2002

Please review the expression.  You do not have an organisation called VIP,  so Organisational Group One ==VIP will not return a match and neither will any of the other org groups. This is why the outcome is  no match. 

The expression should be Organisational Group One== VIP Users or Organisational Group One contains VIP Users

 

 

Mary, yes! I was thinking this myself. This set-up was put in place before I joined, in the project phase. And yet is seems to be working some times. I fully agree and I am going to test this. I wonder whether someone set-up a "VIP" Group at first and then renamed it. Would the flow be using the Group ID in the background still and thus making it continue to work?

[Berto2002]

@Mary Here is the example of where it recently worked with this set-up. Giving me an issue the feeling it's behaving erratically

 

1. BPM20210819000024

...and with this Expression:

And with this User:

[Steve Giller]

@Berto2002 To answer your original question:

Expression matched: 'true'

refers to the "No Match" expression being met.

and an "Expression Matched" statement like the one immediately above indicates a branch other than "No Match"

 

[Guest Mary]

@Berto2002 

The screenshot showing the group association is as it it today and does not confirm what it was in August. 

I'd expect any request logged today to follow the no match route as the value being passed does  not match the criteria i.e. VIP users is not equal to VIP. 

 

[Berto2002]

@Mary the Organisation ID is just VIP, see below... so the use of OG == VIP is correct. This just leaves us the question now of why it is working sometimes and not others... so we are back to the question I originally raised.

[Victor]

@Berto2002 in the "Get User Groups" node, what did you set for "Group Type" input parameter (Option section)?

[Berto2002]

General:

The expression in User ID is:

&[global["flowcoderefs"]["getReqInformation"]["customFieldB"]]

What this does is ensure we are getting the information for the correct person. Our PCF asks if we are logging On Behalf of so one side of the flow adds the Customer who logged the Request to Custom B, the other side adds the other name they gave to Custom B and then Custom B is what we look-up fo rthe VIP choice

I do not know how OGs work but the User was only in four OGs and there are 7 OGs listed in the Expression. What is it in the background that decides that OG the VIP Group is? Will it be one of OG 1-4 because there are 4 of them or could it be that VIP was OG 8 and that was not listed in the Expression? I note that there are 10 OGs in total...

For my reference, the example Request is SR00016632 and the BPM ID is BPM20210907000317 for a Councillor.