Wrong info being pulled into a variable

[SJEaton]

Hi

A user has reported that the wrong date has been pulled into a custom field variable in an email template but on investigation I can't see how this has happened.  I've attached the email that was generated and highlighted the field in question.  The variable for this is {{.h_custom_k}}  which should pull in the 'start date for the proposed higher pay rate' from the procap.  It has however pulled in the 'when will this placement realistically end' from the procap instead  (which is custom field G).  As you can see, the email template clearly shows  {{.h_custom_k}}  and the field ID in the procap is definitely K.    What am I missing here?  Why has this error occurred?

Sam

[Gerry]

Hi Sam,

Does this happen consistently? Would help to know that, it seems odd as custom fields are referenced by their identifier it would seem strange it would use the wrong field.  It could be a problem with the ProCap putting the data into the wrong custom field.   The starting point would be to establish what is in the actual database.  If the data is correct in the database then its a mail template processing issue, but if the data is wrong in the database its a ProCap config issue. 

Gerry

[SJEaton]

How do I establish what's in the actual database?   

[Gerry]

Hi Sam,

You can use the direct database query function in the Admin tool but I would suggest letting our support team guide you through that, they are on the case and will be following up with you very soon. 

Gerry

[Victor]

@SJEaton  your process (the one associated with your example request/email) is currently configured to overwrite custom F, G, K and L with a converted date. The date that is being converted is the value stored in custom G.

So, you do map these custom fields in ProCap but your process will overwrite them... What I think it was intended is to have the date value stored in all these custom fields (F, G, K and L) converted to a specific format. But the implementation is incorrect. You are only converting custom G then use this converted value to overwrite all the other custom fields. What I think you would need to do is one of the following:

A. You would need a distinct conversion node for each custom filed. You can do the conversion and the subsequent custom field update in a parallel processing. If you do this you need a distinct response parameter/context reference for each conversion node.


B. You would need a distinct conversion node for each custom filed. You can do the conversion and the subsequent custom field update in serial/linear order (i.e. one after another). If you do this you will have multiple sets of conversion and update for each custom field, following one after another. In this case, you can use the same response parameter/context reference for each conversion node.

[SJEaton]

Oh ok, thanks @Victor, it looks like I have the wrong custom field in the date conversion so I will take a look and amend.  Sam 

[Victor]

@SJEaton is not exactly the "wrong" custom filed in the date conversion, the field and conversion are correct for its own purpose ... So the conversion is correct for converting Custom G only. All this is fine...

What goes wrong after, is the current "Update Custom Fields" node, whereby the BP (this node specifically) is configured to update all other custom fields with Custom G value... this is why I suggested a separate convert and update sequence for each of the custom fields...

So...

27 minutes ago, SJEaton said:

I have the wrong custom field in the date conversion

Hope my explanation above explains why this might not be technically correct

[SJEaton]

ok, thanks @Victor I think I'll try and configure  option B and see how I get on

Sam

[Victor]

@SJEaton just checking if you managed to implement this and if is now working for you?

[SJEaton]

Hi @Victor, yes we implemented this and it works ok.  Sam