RELATED IDEAS
In workflows, it should not be possible to skip a certain status.
In most workflows, the status "approved" is available. But it can be skipped.
It should be possible to set in a workflow that e.g. a feature most have had the status approved, before it can get any status following it in the workflow. E.g. the workflow is:
- Under consideration
- Approved
- In Design
As long as the status has not been "Approved" it can only be set to Under consideration (so backwards), but not to In Design (aka forwards).
-
ADMIN RESPONSEJan 22, 2020
Just launched!
You can now enforce that a specific status order is followed and require approvals for status changes.
Learn more in our blog post and support article.
4
MERGED
Add workflow validation to control statuses
Similar to JIRA and other tools, would like to see the ability to configure validations to help enforce proper workflow. First, enforce flow from one status to the next and not ad-hoc. Secondly, have the ability to make certain fields required in ...
1
Shipped
© 2024 Aha! Labs Inc.•All rights reserved
Thanks @Ron Yang, I appreciate the clear response, even if it's not what we were hoping for.
I would still maintain this is important for larger organizations who want to take a more formal approach to project approval (stage-gate process, approval tiers). I love Aha's simplicity, but I'm concerned this is one area where it feels we are outgrowing the tool.
We can understand the use case that you are looking to enforce. As you know, we have a lot of flexibility with our workflows and the ability to customize them to your specific products and processes, as well as various user permissions.
At this time, we don't have plans to make changes in this area. We can see some potential painpoints with accidental status changes. This also appears to be an area which can be enforced internally in telling users that only certain employees can make changes to certain statuses.
I agree with this, and the additional comment below. If we could enforce a workflow (specify valid transition states, and which users are authorized to perform them), this would allow us to leverage Aha for project reviews and our overall program management.
Some additional explanation:
In Aha it is possible that roadmaps are changed without any approval of Sr. Management. However, one of the fundamental values of a roadmap is that it's agreed by the whole organisation. It's a formal document.
Ideally, this means that roadmaps are approved by Sr. Management, or by some other authoritative person of body within the organisation. This means that anything influencing the roadmap should be "approvable". E.g. in a workflow with 10 statuses of which "3. Approved" is status number 3, it should be possible to define that the status "3. Approved" can only be set by people with a certain product role (e.g. product owner, or some new to be defined role). Any state after "Approved" (aka 4 - 10) can only be set if the "3. Approved" state was given.