Retain Approval flows on issues after converting to project

[#1]

Description - Approval flows are key functions that often support compliance standards or even legal requirements. Retention of the approval information is essential. Lack of retention has consequences that can devasting to a business if they are audited and found out of compliance.

Why is this feature important to you - What is the point of an Approval flow function if there is no record of it? To reliably capture approvals, I now have to build a workaround, probably with a custom form.

How would you like the feature to work - Retain the decision of an Approval flow indefinitely. Either retain the Approval flow, log the decision in Updates, or both. Bonus points if you give sys admins the ability to lock down the ability to remove Approvals from objects.

Current Behaviour - If you associate an Approval with a request, then convert that request to a project, the Approval is removed from the request. There is no place where the outcome of that Approval flow is documented—not the Approvals area and not the Updates area. Workfront support confirmed that this is behavior as designed.

[#2]

I'm looking for similar behavior. Have you found a solution?

We want to be able to convert an Issue to a Task and have the Task status trigger the Issue approval. Currently, when the status is changed on the resolving Task, the Issue status updates but the approval is not triggered. 

The Issue is being treated as the 'public' work item where the requester can comment to the team, respond to questions, and review drafts of the document. We want the Task to be inaccessible to the requester so the production team is free to add internal comments that the requester doesn't need to be bothered with, such as technical or procedural updates and questions.

[#3]

@douglasca Keep in mind that my idea above is simpler than what you're asking for: When there is an approval on an issue, I want the issue to document that decision forever, even if the issue is converted to something else.

But I'll play ball with your scenario the best I can. I can't say I've heard of anyone trying something like you're describing. In my experience, converting an issue is designed largely as a one-way process with the resolving object being the place where work  and conversation migrates to. There are two settings in the system I've seen that allows users to have private conversations from other users on the same object:

1. In the Access Levels settings you can toggle on the setting "View only updates in which they have been included in the conversation."
2. In the Updates edit box there is a toggle switch that allows a commenter to isolate the comment to their company only. You could feasibly align users to Companies in addition to Groups to make that toggle switch helpful. Users doing the work would need to be diligent about toggling this switch when the conversation should be more private.

Otherwise, you would need to configure your projects, tasks, and documents to not inherit permissions. Some of this you can do at the project template level.

  

[#4]

Thank you @Lyndsy-Denk! This is certainly something to consider as it sounds like what we want is't doable. Our use case is more aligned with an IT servicing system but we have to work with what we have, right? 🙂