Do you have an 'assigned role' field in your Task table? Based on your description above - it might be best instead of thinking about assigning the person to the task, assign the task to a role on the project such as assigning it to the PM, PC etc. Those roles should be defined on your project such that you can add them as lookups into the tasks.
At the task level - you can then make a formula field for 'Assigned To' that does a Case Statement of your assigned role. Something like:
Case([Assigned Role],
"Project Manager", [Project - Project Manager],
"Permit Coordinator",[Project - Permit Coordinator]
....
This Assigned Role would replace individual users in your template since the actual user would be unique and should be carried from the Project Header.
Thanks!
I think that that a case statement for the "Assigned to" field in tasks level might be the solution.
In the project level I will have, as you said, different roles that will be assigned like the field "PM Assigned" as a user. But, I will have more than one responsible per project.
So maybe I can assign in the tasks another field that is Type of Task, and the CASE STATEMENT do it with that field. I dont really imagine how can I do this in an automated way, with the Tasks templates and the pipeline. I will define the assigned to in the task teemplates level? or you think that it will only be a field in the Tasks table?
thanks!
I would suggest following the route that you're describing and where possible - keep the assignments at the project level for the users and then in the template have the 'Assigned Role' and then if you have any qualifiers that might differentiate 'which' PM still in the template itself.
At it's core - even if you tried to do this with a Pipeline, you still need all of these components in the template anyway so the Pipeline would know who to assign anyway. So one way or another if you're assigning the users at the Project Level - then the template still needs to be set up to know which people on the Project are responsible dynamically.
I will always advocate for using Formulas over Pipelines in this case because 1) once the Pipeline runs - its not going to run again so if you need to reset the assignments then you'd need another pipeline to update etc and then 2) a Formula just gives you more flexibility if you need to carve out exceptions or overrides as time passes. Just my two cents though.
Hmm, I have more doubts now.
So, I have a task template table, and I create tasks associated with the project depending on the project's stage using the pipeline. However, there is no relationship between the Task Template table and the Jobs table.
Are you suggesting the use of formulas instead of a pipeline?
I understand that if I have the "assigned to x role" in the project record, then with the pipeline, I could populate the "assigned to" field in the tasks based on the role. Perhaps I'm not grasping it fully; if you could provide further clarification on this concept, I would be grateful.
The pipeline will help me to create the task, associated with the project, when the Proyect is changed to that corresponding stage, but the "Assigned to" will be a formula and not be populated by the pipeline itself?
Thanks!
Your setup sounds fine and I think you're still in a good spot. You would still have the Pipeline create the tasks when the Project Stage changes, and as part of that creation in the Pipeline you would add copy the 'Assigned To Role' Field from the template into the task. Your formula then looks at that field, and then project and plucks out which actual user it applies to. As part of that pipeline - if you have more than one field that helps you identify which role, you would just log all of those qualifier fields to the actual Task related to the Project.
The reason I suggest a formula over having the Pipeline is to give you flexibility that a Pipelin doesn't give you. Imagine for example a PM on a Project changes mid-Project. If when the task was created you assigned it to the PM as part of the creation - then when the PM is updated on the Project you then need a process to go update all of the tasks that were assigned to the old PM. If instead you have a formula that is just referencing the PM field on your project - when you update the project, the formula will fire and automatically update those tasks to the new PM with no additional steps.
