Custom Statuses revert to Default statuses when percent complete is updated

[StephanieSm]

Has anyone else had issues where they have Custom Statuses that equate to In Progress, (ex: "Ready to Test"), but when the percent complete is updated on the Task in that status it automatically reverts back to In Progress? I opened a ticket with Workfront and tried to explain that I thought this was a bug. If I'm already in a status that is equivalent to In Progress, why would it change it? They told me to open a feature request (even though this doesn't seem like a feature at all to me and causes extra attention and clicking) but I haven't done so yet. Anyone else having this same issue and if so, how are you resolving it? Figured I'd ask before posting an idea for voting. Thanks! Stephanie Smith VP Client Solutions Precision

[MattMa1]

Hi Stephanie, we have a similar situation with the same exact problem. If the percentage is changed or time added, it will revert from the custom status back to the "In Progress" default. We were told this is not a bug but rather this is "how the system works." We obviously still need "In Progress" to be the default. Unfortunately, all we could do currently is make our users aware and have them be very careful and switch it back to the custom status after. But to be honest, that doesn't always happen, and it has caused problems. This was before the idea exchange and to be honest, we've simply grown accustomed to "dealing with it," so I never thought to put the idea in. If you do put it in the idea exchange, I'll upvote and rally up as many other votes as I can. Matt May Stream Companies

[Dr_DougWi]

There is good logic for having these defaults across the system. An alternative approach is to treat the status values as a record state instead of a measure for checking a process position or status. This model involves having as few record status values as possible in the main status values set up. This model also includes setting up a custom field for the processes being run on a project, task, or issue. These end up being contextual instead of global when applied only to the items that need them through a custom form. Gone is the idea of custom status values to clutter up the status drop downs and the administration of between group status values; this is simply too hard to manage. I have used this solution dozens of times and highly recommend it across multi-group clients. One organization had 48 status values for project records, which was totally a bear to manage. They had 9 project status values when we finished putting this model in; the independent groups then had their process position markers available to their custom forms instead. Doug Williams

[StephanieSm]

Thanks Matt! They told me the same thing that it was by design and I just can't believe that. It defeats the entire purpose of custom statuses. I did enter an idea on the the exchange if you and anyone else you can rally up want to vote for it! https://support.workfront.com/hc/en-us/community/posts/360001034153-Do-not-automatically-update-stat... Doug - Thanks for the idea. I'm cool with the default statuses and if I'm in a "New" status and do something that indicated progress is being made, then sure, automatically set it to the default "In Progress". In that case, default statuses are very useful. But we are an agile team. Our tasks/projects move from New to Ready to Quote to Ready to Schedule to In Progress to Ready to Test to Write Release Notes to Ready to Merge to Complete - so 8 total statuses. The first three are equivalent to "New" and the last two are equivalent to "Complete. This leaves three in the middle equivalent to "In Progress" and helps to indicate progress across our scrum board. The tasks move through each swim lane as they reach another step in the process. This allows PMs to see from the scrum board where things are sitting for the iteration. Custom forms are great, but a pita (excuse me) when having to report off of quickly and to my knowledge cannot be seen from the scrum board which is our main source of determining progress. It's an interesting concept, but I'm just not sure how feasible a custom form would be and technically, we already have a place to indicate the state or status. I just simply want it to not automatically change if its already in an equivalent status. Stephanie Smith Precision

[VicAl]

Just FYI (especially for anyone new). They use the term "by design" a LOT. They even have buttons they wore at the last Leap proclaiming that. I would love to see this Design Document some day �� Vic Alejandro, PMP, CSM | IT | Sr. IT Project Manager Denver Water | t: (303-628-7262) | c: (303-319-6473) "http://www.denverwater.org/"> http://www.denverwater.org INTEGRITY | VISION | PASSION | EXCELLENCE | RESPECT

[Doug_Den_Hoed__AtAppStore]

Hi Stephanie, Thanks for writing this up. Your usecase makes sense to me: your team is using three different kinds of In Progress. Several years ago, I noticed that when the Status of an Issue was set to the built in Awaiting Feedback, once a reply was made, the Issue Status would automatically switch to In Progress, implying that the conversation had resumed, and progress could again be made. From a Helpdesk perspective, I can see how that makes sense too. My guess is that similar functionality is also being called where the percent complete is updated (e.g."if the percent complete is moving, things must be In Progress")...but as a side effect, by not checking whether the current (custom) status Equates With "In Progress" and instead poking the In Progress status itself, it is effectively reverting the progress your Agile Team had indicated. In situations like this -- where Workfront's As Designed behavior isn't quite as you'd want it -- I usually try to bend the rules; either the business rules, or Workfront's. In this case, I can offer three such rule bends for your consideration: change your business procedure to ensure that whenever the percent complete is changed, the status is also (re)confirmed, in order to "keep it" where it was create an Issues Exception Report that checks for Issues that "got reset" by filtering for Issues whose Status is currently "INP" (In Progress) but whose Previous Status (which is a VERY handy field, btw, for those reading yet to have a formal introduction) was something OTHER than INP, and grouping the report by Previous Status so you can efficiently manually update the Issue status values back to what it ought to have been. So! In your case (taking a guess at your Status codes) using "RTS" (Ready To Schedule) OR "RTT" (Ready To Test), here's how that filter would look in Text Mode: previousStatus=RTS previousStatus_Mod=in status=INP status_Mod=in OR:1:previousStatus=RTT OR:1:previousStatus_Mod=in OR:1:status=INP OR:1:status_Mod=in if the second bullet does the job but is too inefficient to perform manually, consider automating it using the API, or with our "http://store.atappstore.com/product/ubercalc/">UberCalc solution Regards, Doug Doug Den Hoed - AtAppStore Got Skills? Lend a hand! https://community.workfront.com/participate/unanswered-threads

[StephanieSm]

Thanks Doug - this was very very helpful! I appreciate you taking the time to write it all out. We have told the developers about "re-confirming" the status, but will definitely need to put the report in place to be sure we don't miss anything. Hopefully I can rally enough votes so this is a temporary fix. Thanks again! Stephanie Smith Precision

[Doug_Den_Hoed__AtAppStore]

My pleasure, Stephanie -- happy to help. I think the change you are proposing would be an improvement, and would vote accordingly. Regards, Doug Doug Den Hoed - AtAppStore Got Skills? Lend a hand! https://community.workfront.com/participate/unanswered-threads

[MariamPa]

Hi Stephanie, Thanks for starting this conversation in our Community portal. I am the Product Manager over Administration & Configuration aspects of Workfront, and want to let you know that I share your concerns regarding the behavior in question which I believe is a functionality oversight. I have asked the Support Representative assigned to your ticket to escalate your request to Development for further review and fix. The ticket will be addressed based on its defect severity (which I tend to think is Medium). In other words, you will not need your Idea to reach 45 votes to have the expected behavior in the product :) Thanks for helping us make Workfront a better product. Kind Regards, Mariam Paronyan, PMP Product Manager Workfront

[StephanieSm]

Thank you so very much! My team and I greatly appreciate it! Stephanie Smith Precision

[Kelly_Wehrmann]

@Doug Den Hoed , thanks for sharing....when did Previous Status come onto the scene? I don't recall seeing that before. Admin Kelly-Wehrmann SSFCU

[Doug_Den_Hoed__AtAppStore]

Previous Status has been there quite some time, Kelly. I first noticed it in early 2016 when I developed our "http://store.atappstore.com/product/sla-package/">Service Level Agreement Package. But my guess is "forever". Regards, Doug