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:

  1. Under consideration
  2. Approved
  3. 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).

  • Ivar Slavenburg
  • Aug 12 2015
  • Unlikely to implement
Release time frame
  • Attach files
  • Ivar Slavenburg commented
    August 27, 2015 09:44

    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.

  • Chris Maddocks commented
    November 24, 2015 22:45

    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.

  • Admin
    Ron Yang commented
    December 3, 2015 22:50

    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. 

  • Chris Maddocks commented
    December 7, 2015 19:11

    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.