Jump to content

Branch on Progressive Capture Question - using Display Value not actual Value


Recommended Posts

I noticed that when branching on the response to a progressive capture question, which is set up as a static list, in the BPM the value you have to use in the condition is the Display Value and not the actual value.

Is there a way to set the condition to use the actual value rather than the display value, as the latter can something be a lot longer and something will be changed as it is descriptive whereas the actual value column would not?

Cheers

Martyn

 

branch2.PNG

branch1.PNG

Link to comment
Share on other sites

@Martyn Houghton something that needs to be considered by our dev team... I was thinking as a workaround, since you are using the actual value in the display value, to use the "LIKE" operator in the expression? This way you can rename the display value and not need to have the BP amended (this as long as the display value contains the actual value). So your expression would be: <variable> CONTAINS <value> or <variable> STARTS WITH <value> (e.g. Custom PCF->Variable contains "High" or Custom PCF->Variable starts with "High"

Link to comment
Share on other sites

@Victor

Thanks for the advice. If you can let me know the outcome of the discussion with the dev team. Not sure if this down to the change from the deprecated Get Request Questions, or just something it has always used the display value.

We starting to add more text into the display values to explain the options to the end user.

Cheers

Martyn

Link to comment
Share on other sites

  • 2 weeks later...

SM should be storing the captured value as the bare minimum not the display value....That's the whole point of value/display pairs.

Those list item displays are also translatable so can have scenario where the stored display is in French for example so testing against display value is not advisable.

Sure somone from SM explain why they store the display and not the value (i assume to do with showing answers in reports or something). I imagine can be easily sorted out by adding a new column to db table to store rawvalue if question type is a value/display control. The flowcode to then return pcf answers can be modified to return the rawvalue instead of display value if there is a rawvalue stored.

@Victor have SM team come back to you?

 

Link to comment
Share on other sites

That's something I picked up a long time ago with @Bob Dickinson... It is the same with feedback forms too. In both cases, we only store the text, not the value. This particular coding is a real issue when you start considering translations too as the values stored in the database will be the translated text of the answer !

As for reporting (on feedback for instance), it makes it almost impossible to do any form of calculation within Hornbill which is a great shame :(

Link to comment
Share on other sites

1 hour ago, Lyonel said:

That's something I picked up a long time ago with @Bob Dickinson... It is the same with feedback forms too. In both cases, we only store the text, not the value. This particular coding is a real issue when you start considering translations too as the values stored in the database will be the translated text of the answer !

As for reporting (on feedback for instance), it makes it almost impossible to do any form of calculation within Hornbill which is a great shame :(

I remember this discussion @Lyonel , we did raise and discuss this internally at the time - I'll have a look for this and see what progress we made, previously. 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...