Make a Decision Flow action not returning Result Record

David House
Tera Guru

I am trying to implement a decision table into my Flow, but I am having some difficulty getting any output from the Make a Decision Flow action.

 

Specifically, my issue is that I cannot seem to get a usable Result Record when I am not using "Use Brances".

 

When "Use Branches" is ticked, I get the expected outcome of several branches based on my outputs within the decision table:

DavidHouse_0-1670915908116.png

 

However, in my case, since I am receiving an "Action" and an additional "Access to grant", I do not wish to divert to a separate branch for each possible outcome. Instead I would like to divert using an IF based on the "Action", then utilise the "Access to grant" within the IF.

 

To do this, I should be able to simply untick "Use Branches", then use an IF based on "Action". The problem is that I cannot seem to access the Result Record to get either output properties.

This is the pill in the side bar while expanded:

DavidHouse_1-1670916115282.png

(notice the lack of any properties)

 

This is what I get when dot-walking in the IF:

DavidHouse_2-1670916196413.png

(notice the "No matches found")

 

As you can see when I have "Use Branches" ticked, it is giving me the outputs, but for some reason I can't access them when it's unticked.

 

Has anybody run into this issue before? Does anybody have any pointers for me to try?

 

Thanks in advance.

 

Edit: Additional note, I have tried both options for "First decision that matches" and "Run all decisions that match" with the same result.

 

Also, I tried in a PDI with the same decision table and I do get the expected output:

DavidHouse_0-1670935890810.png

 

This leads me to believe it may be something to do with our instance.

1 ACCEPTED SOLUTION

Hi Matt,

 

Thanks for continuing to help.

 

I have done some further testing and found a potential cause (still not sure on the exact root cause though).

 

I was getting the same expected output as your screenshots in my PDI, but my issue appeared to be specific to my instance. However, I have now been able to get the decision table to work as intended by switching to a Global decision table instead of one within an application scope.

 

The confusing part is that I had the decision table in the same scope as the flow I was attempting to use it in. If you see in my screenshot, for testing, I now have 2 identical decision tables being called within my flow (flow is within an application scope that is not Global), but only get the contents of the result record from the decision table that is in the Global scope:

DavidHouse_0-1672709276016.png

 

Both decision tables are also marked as available from All application scopes:

DavidHouse_1-1672709675890.png

 

--------------------------------------------------

 

Testing the same thing in my PDI works fine for scoped decision tables and flows.

 

Further testing in my instance works fine in another application scope, so this narrows the issue down to the specific application scope I was trying to use.

 

 

Conclusion

In this particular case, I am fine to use a different scope, so I am not going to dive any deeper into why that first scope was preventing decision tables within its own scope. Food for thought for if anyone else runs into this same issue, I suppose.

View solution in original post

5 REPLIES 5

MattSN
Mega Sage
Mega Sage

When you untick branches, you have to do 1 of 2 things.

  1. If you only need a single response, Set Execution to "first decision that matches"
  2. If you need multiple responses, use a "for each item" flow action to loop through the matches. See Demo - https://youtu.be/NtAjgcQg5YQ?t=1889  
Join us live as we bring some of our processes into decision builder for the first time.

Hi Matt,

 

Thanks for the reply.

 

I've tried both options so far. I probably should have specified that in my question as well, but the screenshot is from the "first decision that matches" option. 

 

Using the multiple matches option still produces the same outcome when I try to access the item within a For Each loop.

Hi David,

 

If you're using "first decision that matches" and unchecking "use branches", it should look something like this. (sample is using a decision table that returns a group for a result). If you still can't dot walk, it could an issue with the decision table. See https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0870208 

 

Decision Config

MattSN_1-1670958829790.png

If statement

MattSN_0-1670958796925.png

 

 

 

 

 

Hi Matt,

 

Thanks for continuing to help.

 

I have done some further testing and found a potential cause (still not sure on the exact root cause though).

 

I was getting the same expected output as your screenshots in my PDI, but my issue appeared to be specific to my instance. However, I have now been able to get the decision table to work as intended by switching to a Global decision table instead of one within an application scope.

 

The confusing part is that I had the decision table in the same scope as the flow I was attempting to use it in. If you see in my screenshot, for testing, I now have 2 identical decision tables being called within my flow (flow is within an application scope that is not Global), but only get the contents of the result record from the decision table that is in the Global scope:

DavidHouse_0-1672709276016.png

 

Both decision tables are also marked as available from All application scopes:

DavidHouse_1-1672709675890.png

 

--------------------------------------------------

 

Testing the same thing in my PDI works fine for scoped decision tables and flows.

 

Further testing in my instance works fine in another application scope, so this narrows the issue down to the specific application scope I was trying to use.

 

 

Conclusion

In this particular case, I am fine to use a different scope, so I am not going to dive any deeper into why that first scope was preventing decision tables within its own scope. Food for thought for if anyone else runs into this same issue, I suppose.