New custom data fields 31-40

[Adrian Simpkins]

Hi All

I seem to have found an issue with the new custom data fields being used within a BPM to drive a decision. I have a BPM where I was using custom data field 36 to control the priority a request was raised under using the Customers selections to meet a certain criteria. This initially worked when I changed the BPM to set anything with a Yes value in custom data field 36 to set as priority 2, and my no match was priority 4. However, the team using this BPM reported that requests that should be level 2 were setting as level 4.

I reviewed the script and could not see why this was happening, but due to some other issues I noticed in other requests (some data display issues in the details tab, as well as in an activity, or summary, or description field where I used one of the new data fields). I thought I would test this by swopping the data field to one of the original custom data fields - o. The script now works correctly with no issues after removing 36 and replacing with o.

I will add an example of where the new fields are not working in activities where I call the value for the analyst to use when actioning requests, as well as the other data display issues I mentioned, but wanted to raise this and see if anyone else has had the same problem

Thanks !

[Victor]

@Adrian Simpkins on top of my head, custom 36 is a filled of type INT meaning it will store only numeric values... are you storing numbers in it?

[Adrian Simpkins]

Morning Victor

The WIKI shows the new fields 31 to 40 as Text fields rather than numeric as below. However, after doing some more fixes to existing BPM's that were working correctly, I think it is not limited to just the new custom data fields. For example I have one BPM where I have a decision node at the start to assign to different teams dependent on the Customers selection - this was working fine when tested and made live, but now for some reason it ignores the logic on the decision and just goes straight to the No match option so all requests assigning to one team only. The fields in use here is h_custom_c - I went back into the BPM and removed the node and recreated it, still didn't work,  I also tried using opposite logic on the decision node - still didn't work. I have now recreated the whole BPM and now it works fine with no issues using the exact same logic I had on the original BPM .

So my query is really to understand why a BPM that is working correctly would then ignore the logic - this BPM has had no major changes at all (others I have worked on had a lot of changes made)

Many thanks

h_custom_31 - h_custom_40

TEXT/unlimited*

[Victor]

@Adrian Simpkins all right, I've mistaken custom 26 with custom 36 ... 26 is the INT one...

3 hours ago, Adrian Simpkins said:

why a BPM that is working correctly would then ignore the logic

There are some aspects we uncovered recently around BP asynchronous execution (nodes can execute in parallel or better said, a subsequent node can initiate before previous node is fully completed) and database caching. In certain scenarios, the values used in expressions on decision nodes do not contain updated data meaning the evaluation for branching is done on outdated information leading to issues such as the one you noticed. Now this happens intermittently because it depends on how fast the node execute (which can vary) or how fast the DB cache updates.

It would be good if we can confirm this, I'll raise a support request to investigate this in more detail.

I will update this post with our conclusions.

[Adrian Simpkins]

Thanks Victor, yes please if you could ask for some digging, as I feel like I am chasing my tail a lot of the time as I keep seeing these BPMs which appear fine and correct, then they will not function correctly!

I await your further comments

Many thanks as always !

[Victor]

@Adrian Simpkins - I know you have updated @Steve Giller recently regarding the support request to have it closed off. Just wanted to add here my findings as well. Unfortunately I could not fully troubleshoot this issue. What I can say is that, taking SR*6466 as an example, the workflow failed to branch on Custom 36 value because this field in the table does not have a value for this record. I don't see any configuration where this value might be overwritten so my assumption is that it wasn't captured or something happened during capture (somehow, but I don't know...). I wasn't able to replicate any scenario where I have Custom 36 mapped during PCF and not have it stored in the DB. I have also looked in comparison on SR*6666, a request raised a day later which does have a value for Custom 36, stored during progressive capture. If you have a chance would be worth trying to redo the Custom 36 test which failed for you then have another look...

[Adrian Simpkins]

Hi Victor,

thank you for the update. As I have new BPMs in place with corrected values the issue appears to be rectified ! If I do come across this situation again I will copy out the BPM before making changes to allow you a better route to investigate.

Many thanks as always