Skip to main content
Planview Customer Success Center

Lifecycle States

AdaptiveWork Projects and Work Items have 6 defined States which can be set by Project Managers and Work Item Managers (not by Resources or Reviewers)

360023768594_mceclip1.png Requested - Typically indicates that the work has not yet been fully scoped, resourced or committed.

360024725373_mceclip2.png Draft – The planning stage. Scoping out project work, budget and resourcing.

Note about drafts and requests: Draft is the default state for new work items. The key differentiator is that Requested work items are not shown by default in the Resource Load, allowing you to easily filter out work that is still being defined.

Best Practices

  • If you're using Requests to hold simple project requests for initial review before scoping out a project, consider converting the request first into a Project in Requested state where you will plan out top-level Project assignments and non-labor resources without creating a full work breakdown and committing resources. Note: requested work items' costs, revenues and efforts do aggregate up.

  • If you want to report time on Requested work items - for example - you spend 3 days scoping out a project request or a requested change to an existing project, you should enable the system setting to allow reporting timesheets.


360023768614_mceclip3.png ​ Active - When your project is ready to start. It is fully scoped, fully resourced and is ready to begin execution,

it does not matter if it has not reached its targeted start date. Tasks and milestones may have dependencies on predecessor tasks and milestones, so whilst a task may be active it may not yet be Executable .

360024725393_mceclip4.png ​ On Hold – if a project or individual work item has stalled for some reason, such as the customer postpones a decision,

budget is exhausted, project sponsor drops support.

360023768634_mceclip5.png ​ Cancelled – the project or individual work item will not be executed.

360024725433_mceclip6.png Completed – No further work is planned.

If your organization is using timesheets it is important that Project Managers Activate their projects as tasks which are not Active may not appear in resources' timesheets (System Setting 10.4 defines this)
Project Structure
By default, when you activate a project, all of the sub projects, milestones and tasks contained within it will be activated.

AdaptiveWork also supports "rolling wave" planning, where one part of a project is being planned while another is being executed.

  • example 1: a project where the first milestone is a viability study or sales process that the following milestones are dependent on. In such a case, you can choose to activate the initial milestone without activating the entire project.
  • example 2: you may choose to manage the entire project manually by building an approval process that will formally activate each milestone when the predecessor is approved completely.

State icons in the current project screen (WBS)


Updating Lifecycle State

Project Manager in AdaptiveWork has full control over all work and related objects in the Projects they manage so they can change the state of the Project

or any of the work items contained in its hierarchy.

Work Item Manager (e.g. Manager of a task, milestone or sub-project) can change the state of the individual work items that they are responsible for

or of any of the work items contained in its hierarchy (e.g. sub tasks)

Super Users can change any work items in the whole organization so they can change state of any work item in their organization’s AdaptiveWork account.

Resources can change work items from being active to completed by marking them as 100% complete or by reporting enough hours when using

Actual & Remaining Effort methodology (system setting 9.3)

Reviewers & Project Sponsors have no ability to update the work plan (WBS).

Lifecycle State Behaviors

Note: If you re-activate a completed work item , the %Complete and Remaining Effort fields will appear with a "(?)" indicating that AdaptiveWork is now uncertain of the data it has and user input is needed to verify or update these fields.

Requested state behaves the same as Draft.

Changing states via Workflow Rules

If you want to build configurations that modify work items’ states you need to use the dedicated “Change State” action, rather than simply updating the field to the new value.