I solved it, Kristy (and Justin). In your calculated form, the PPS Audit Reschedules calculated parameter (where you're adding 1 to track the number of edits) also referred to the PPS Reschedule History calculated parameter. During some heavy testing when we created our "https://store.atappstore.com/product/force-custom-data-double-recalc/" Recalc Parameters solution, I learned that Workfront's calculation routines are iterative in such cases: the first pass calculated both, then (recognizing the dependency) a second pass recalculates the PPS Audit Reschedules...hence, your 2. Realizing that, I changed the formula to add .5 (rather than one), made an edit, and confirmed that the count was then .5 + .5 = 1, as desired. But that seemed pretty fragile. In practice, I recommend "flattening" such calculations by embedding the entire calculation of the PPS Reschedule History calculated parameter's formula into the PPS Audit Reschedules parameter, or at least, the part that matters, having noticed that you'd used LEFT(...m,8) in one formula vs LEFT(LEN(...)) in the other. My observation is that as long as the syntax is exactly the same logic, Workfront foregoes the second pass (so, less fragile). As a result, here are the two formulas I settled on, using the latter technique, and -- yep -- confirming that the count of the changes goes up 1 at a time, as intended. PPS Audit Reschedules: IF(LEFT(PPS Reschedule History,LEN(IF(ISBLANK(1st Reschedule Date),"-",1st Reschedule Date)))=1st Reschedule Date,PPS Audit Reschedules,SUM(PPS Audit Reschedules,1)) PPS Reschedule History: LEFT(IF(LEFT(PPS Reschedule History,LEN(IF(ISBLANK(1st Reschedule Date),"-",1st Reschedule Date)))=1st Reschedule Date,PPS Reschedule History,CONCAT(IF(ISBLANK(1st Reschedule Date),"-",1st Reschedule Date)," (on ",$$NOW,") because ",1st Reason for Reschedule," | ",PPS Reschedule History)),2000) Regards, Doug Doug Den Hoed - AtAppStore
