SJEaton Posted October 26, 2017 Posted October 26, 2017 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 Posted October 26, 2017 Posted October 26, 2017 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 Posted October 26, 2017 Author Posted October 26, 2017 How do I establish what's in the actual database?
Gerry Posted October 26, 2017 Posted October 26, 2017 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 Posted October 26, 2017 Posted October 26, 2017 @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 Posted October 26, 2017 Author Posted October 26, 2017 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 Posted October 26, 2017 Posted October 26, 2017 @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 Posted October 27, 2017 Author Posted October 27, 2017 ok, thanks @Victor I think I'll try and configure option B and see how I get on Sam
Victor Posted November 8, 2017 Posted November 8, 2017 @SJEaton just checking if you managed to implement this and if is now working for you?
SJEaton Posted November 13, 2017 Author Posted November 13, 2017 Hi @Victor, yes we implemented this and it works ok. Sam
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now