Tuesday, April 24, 2012 2:14 PMWe have a scenario where our service team work on several tasks that are dependent on many other tasks. ie. our mech should not work if the dependents tasks are at least 60% completed. I tried to create a custom entity "Service Task" and link to dependent task (but the problem is that it is dependent on more than one task so I created a child entity). But I would prefer to keep one entity for tasks. I am wondering if you have come across such scenario and how you have handled it. I have to write a plug-in that deactivate the parent until all the related tasks are completed so that our mech. don't accidentally work on tasks.
Wednesday, April 25, 2012 9:36 AM
Create a self referring entity. Your primary entity in question is "Service Task", which itself is a task. If a dependent task is entirely too different than a "Service Task", then make the dependent task a self referential entity.
* Service Task -> Dependent Task (A Service Task With A 1:N Relationship ... this will actually wind up being a 1:N and a N:1 relationship because it's self referential.) - In other words, it's a tree structured.
* From here you can create a subgrid on the form, displaying all dependent tasks.
A dependent task can be determined by the look-up field to the "Parent Service Task". If the Parent Service Task field is not populated, It would be considered a top level task.
Wednesday, April 25, 2012 12:44 PM
Hi Travis, that's what I considered earlier. Here, each service task can be dependent on more than one. say service task 1, 2 3. Task #3 is dependent on #1 and #2. Will I be able to say list Service task #1 & #2 for the parent #3 without having to create parent-child entities?
ie. Can I be able to add service tasks (more than one) in the sub-grid for a parent task? Task #3 will have two parents records 1 & 2
Wednesday, April 25, 2012 6:32 PM
In that case you'll want to create a N:N relationship instead of a 1:N. The only caveat to this is that you cannot use a subgrid to display the parent tasks in a subgrid, you'd need to setup the relationship to display it in the navigation of the record. The other issue with this is that it allows a unstructured task dependency that may lead to confusing data at times but is less confining and allows for a very complex dependency structure.
To refine this idea further, you can approach it from a Mixed standpoint, where the 1:N Tree gives your basic parent : child relationship, and a N:N relationship for the cases where you have a task that is dependent on an entirely different Service Depentend Task. Its just a matter of how complex your data structures and relationships need to be. The drawback from this approach is that you cannot show the N:N dependent tasks in the tree task view.
- Edited by Travis-Sharp Wednesday, April 25, 2012 6:34 PM