I've not seen precisely the issue as described, but we did chase down a particular bizarre behavior with Custom Forms that overlaps pretty significantly. In my instance, the initial issue was reported to me as people having submitted a particular Custom Form without filling in a required field. When I reviewed the data on the Custom Form, the reports were seemingly correct, the 'required field' functionality hadn't worked properly (or so it seemed at first). In speaking with the people completing the forms, they were absolutely insistent that they had completed that particular field, and the issue was wide-spread enough to not simply be one person working too quickly. We did isolate the issue to one specific field on the form though, and that proved the issue.
Through a combination of screenshots, logging in as myself and logging 'in as' the affected users, we realized that while they all seemed to be seeing the same form - they weren't seeing the same VERSION of the form. The text label displaying for the affected field had been updated to clarify it, a seemingly innocuous change. In version A of the form, the field was called "Date and Time", and in version B of the form, the field was called "Date and Time - CST".
If the end-user's browser had a cached copy of version A, then they completed the field 'Date and Time', passed the required field validation, and were able to successfully save the form. However, once the data reached the database, no field called 'Date and Time' existed - and the information input vanished. Thus the user viewing Version B perceived that the required data hadn't been properly completed, even though the submitted knew they had completed it.
I suspect that your custom form modifications ARE being instantly applied - the end user's browser simply isn't refreshing the version of the form they're being served. Or in Kevin's example, the timeline IS being recalculated as expected - it's just not being served to the user correctly. I don't know anywhere near enough about web-dev to know if this is a problem Workfront even CAN solve, or that's a function of browser caching behavior that's outside their locus of control.
For our environment, if we make any key changes like that, we send out a note with instructions on refreshing their browser cache so they see the updated information. This is one that's nearly impossible for an admin to test, since our browsers will "see" the updated form even if an end-user doesn't. (Seriously, I thought I was losing my mind, the screenshots were the only thing that let me untangle it.) In a larger environment, I might have my IT team set-up a remote machine for me to use for this kind of testing so I could truly be in a different environment.
Having written all of that, I re-read the initial writeup and I see you're noting that when you log-in as the user you're seeing the form differently than when you're in your own account, which is slightly different than my scenario. At that point, I'd have to look at how complex that formula is, and how many instances of it exist in your implementation. I'd expect a complex calculation that exists thousands of times in an implementation to take longer to recalculate across all the projects than a simple one that exists on only a few projects. If I had to test it, I'd run a report showing the result of that calculation across all projects and save it offline. Then make my change, and run that report again. Can you identify a pattern of projects changed/not changed etc? Do they all appear updated in the report, but not when you log in as those users etc?
Not sure what I'd expect to find, but that would be my initial troubleshooting in your shoes.
Katherine
