Calculation Fields Inconsistent

[emilyp7772345]

Hi All! Since the roll-out of the new features last week, we've had a lot of issues with our calculation fields. It seems like the syntax is either unexpectedly changing or very inconsistent. I'm curious about how widespread the issue it. I've got one form right now that has a calculation requiring new syntax at the top and still using old syntax at a calculation at the bottom of the form. Both are acceptable and calculating correctly, which leaves me very confused. Not easy to debug when the logic isn't consistent. Thanks! Emily Emily Pandzik Staples, Inc.

[AdinaPi1]

Following this, since I'm having the same problem. I've already spent about 2 hours troubleshooting a few calculations. Adina Pierce Cisco

[emilyp7772345]

I wish it was two hours, we were in the middle of a roll out when these started. 🙂 Took almost a whole day to figure out the basic problem and then update. The frustrating thing is the lack of consistency and communication, made especially difficult since we were at the end of our billing cycle when the update happened. Emily Pandzik Staples, Inc.

[DavidCo3]

Hi Emily, What are the syntax changes? Are they documented anywhere? We have a number of calculated fields which I haven't needed to edit yet but it's only a matter of time. Thanks Regards, David Cornwell Pentana Solutions

[j_allen1]

Emily and I have been seeing the most issues with: Nested IF statements and either needing { } brackets around field names or not. Sometimes the calculation editor removes them, sometimes it doesn't. It seemed to vary from day to day since R2. We used to add fields by using fieldname + fieldname , but we've had to change everything to use the SUM function. A couple of days after the release, the same issue with (+) started to affect our (*) multiplications, so we had to swap those out for PROD expressions. This is where things got VERY odd because in the same form we had this: IF({Request Type}="Creative Brief Design",SUM(PROD(Hours at Prepress Rate,Master Prepress Rate),PROD(Hours at Design Rate,Master Design Rate)),IF({Request Type}="Revision or Alteration",Calculated Revision Cost,IF({Request Type}="Rate Card File Review",ATTC Rate Card File Review*Master Prepress Rate,IF({Request Type}="Rate Card Design",0,0)))) Lower in the same form is another calculated field: IF(Revision Type="Super Light",(ATTC Super Light Alt*Master Prepress Rate),IF(Revision Type="Light",(ATTC Light Alt*Master Prepress Rate),IF(Revision Type="Medium",(ATTC Medium Alt*Master Prepress Rate),IF(Revision Type="Heavy",(ATTC Heavy Alt*Master Prepress Rate),IF(Revision Type="Super Heavy",(Quoted Revision Time*Master Prepress Rate),0))))) One works with { } brackets and PROD expressions, the other works with no { } brackets and (*) as a multiplier. But changing one of these to match the syntax of the other made it stop calculating. That's when we let out a collective sigh and decided to stop for the day. 🙂 I would just ask the Workfront team that if there are going to be any syntax changes, to let us know before the release hits. I remember mentioning one thing in the R2 webinar about slashes and commas, but it wasn't anything that affected us so I somewhat ignored it. This all hit in the middle of a billing cycle for us, so it was incredibly disruptive. 😞 Jennifer Allen Staples, Inc.

[OndinaSt]

Also following this thread since I'll be working on nested IF statements today. Thank you for posting! Ondina Sturges Everyday Health Inc

[DrewCo]

We've had the issue with the { } or no { } being inconsistent for a long time. It's really frustrating because you have to write the expression with the brackets but when you save the system removes them. If you happen to click back into that field you have to add the brackets back in otherwise it says there's an error with the calculation. I've spent lots of time on the phone with support about this and never got a clear answer. Drew Conklin Reliant

[Doug_Den_Hoed__AtAppStore]

Hi Drew, My sense of the disappearing { } behavior is that it is the calculation editor box itself in the form builder wizard that "helpfully" strips the brackets out if and when you click a formula to look at it, although testing it is bit like the old Does The Fridge Light Really Go Off When The Door Closes paradox. It can be especially troublesome if the parameter names happen to match built in Workfront field names. For example, I used to have a Project level one that I foolishly named "Portfolio", so when {Portfolio} became Portfolio, things broke...so I renamed it to "Project Portfolio", and encourage others to avoid making a similar mistake. That said, the API does not do the same substitution, so several years ago, we created our "http://store.atappstore.com/product/populate-category-generator/">Update Category Generator and "http://store.atappstore.com/product/populate-category/">Update Category solutions to export and then manipulate/import Custom Form definitions using Excel respectively, which is how I personally administer my (very large) Custom Forms. Regards, Doug

[KathyLe1]

Adding to the list of things that seem to fix broken calculations: I had an IF(ISBLANK({fieldname})="FALSE",blah,blah) that stopped working. Changing the "FALSE" to "false" fixed the problem. I don't know whether ISBLANK used to produce an upper case result, or whether they are now using case sensitivity in their evaluation. Kathy