Skip to main content
Question

Managing Project Tasks & Status

Let's say that I have a Projects table with a Status field where each status acts as a state that drives which Role is tasked with working on that project so that the Project can advance to the next state.

For example, a Project may have a status called "Under Review" in which user(s) in the Project Manager role needs to perform a set of tasks or checkpoints on the Project before the status is automatically changed to "In Progress".

What is the recommended way to implement this? Specifically, how should I:
  • Create a set of tasks or checkpoints that must be finished for each Project Status
  • Automatically advance the Project Status to the next status once all tasks for that status is complete
The tricky parts that I'm trying to work through are:
  • If I create a Tasks table, I don't want to have to duplicate the same tasks for all Projects - that would end up using a lot of space over time given that each Project may have some 50+ Tasks across the different Statuses.
  • How to safely advance the Project Status once the criteria for the current project status has been met. I don't want some of roles to be able to just manually toggle the Status of a Project. Advancing the status should be a function of completing all required tasks for that stage.
Ultimately, I'd like full visibility into the status of all my Projects and the outstanding items that need to be addressed in order to move the Projects forward.

Any advice would be appreciated.
    This topic has been closed for replies.

    Be happy to demo a custom app that does this and a little more but can be removed if you don't want it. chuck@chuck.support 
    • MCFNeil
    • Registered
    • July 21, 2017
    This is a big process to get this, but the cliff notes version is;

    You will want to have a Task table, a Template Task table, and a Project Type table.

    Basically you will want to have a template list of tasks for the project, based on the project type.  
    The reason you break this up is multi faceted, but some of the reasons can include, different lists dependent region of task, client requirements, details with equipment, or general changes in process over time.

    When you make a new project, and pick the project type, a script will then load the most recent and applicable task list.

    Yes, over time it could be a lot of records, but the tasks are very minimal information, and all of that info is connected to the project and the task driven status.
    I'm not understanding why Josh can't use the native button set up by the native wizard to import the stabndatd set of temp,acted tasks. That button can be also natively configured to import unlimited levels of grandchildren.

    I agree, that there is no concern about creating a whole lot if task records. They are lightweight records. You could have 100,000 of them with no performance o r space limit problems.
    Terms & ConditionsAccessibility statement