Jump to content

Wrong info being pulled into a variable


SJEaton
 Share

Recommended Posts

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

Capture.PNG

Capture.PNG

Capture1.PNG

Capture.PNG

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

@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.

image.png

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.
image.png

Link to comment
Share on other sites

@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 :)

Link to comment
Share on other sites

  • 2 weeks later...

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
 Share

×
×
  • Create New...