Parent - child relationship between custom tables

[G Balaji]

Hi,

I've a custom table "Profile" that extends OOB task table. There is another custom table "Profile tasks" that extends "Profile" table. I've created "Profile tasks" to save the tasks created for the records in "Profile". 

I'm not sure how to set up a parent-child relationship between these tables, Parent(Profile) table and child(profile tasks) table. 

For every record created in profile table, associated tasks has to be created in "Profile tasks" table.

Could somebody set up pointers to this?

Thanks.

[Mark Stanger]

If both tasks extend the 'Task' table, you could just use the existing 'Parent' field (and associated related list) to track this relationship.  If you want to create a new, specific relationship just for your 'Profile' and 'Profile tasks' records, just create a new reference field on the 'Profile task' form named 'Profile' that references your 'Profile' table.  Then you can add the corresponding 'Profile tasks' related list to the bottom of the 'Profile' table and track things that way.

[G Balaji]

Thanks for the response, Mark.

What would be the impact if I changed the reference of the Parent to my "Profile" table as reference.

That way, I don't have to create another column.

Is that a good practice if I did as I mentioned above.

To detail you about my requirement,

There is a workflow running on my "Profile" table and there would be a task activity in my workflow which I plan to save in "ProfileTask" table. So, what would be the impact if I set the Parent column reference to "Profile" table?

Appreciate your active participation in the community.

[Mark Stanger]

You don't want to do that because then you override the 'Parent' field for the entire task table.  You'd be better off just creating a new field.  I also agree with Jim's comment below that your 'Profile tasks' table should extend the 'Task' table just as your 'Profile' table does.  This is the same way it's done for Problem/Problem Task, Change/Change Task, etc.

Please mark this answer as correct if I've answered your question.  Thanks!

[Jim Coyne]

Not the subject of your question directly, BUT, you should reconsider extending the "Profile tasks" from the "Profile" table.

Here's another post about that from a few years ago - Incident Tasking - Extend Incident or Task Table?

Based on that earlier post, I'd modify my answer for you to be:

"I actually disagree with the idea of extending the Profile table.   I would, and have created a Profile Task table, but by extending the Task table instead.   Most of all the fields you would probably need are on Task anyways.   All you need to do is add a reference field back to Profile and you are probably done.

Extending the Profile table does not give you a logical Parent/Child relationship, but more of a different "type" of Profile.   Just like how Incident extends the Task table, it created a different type of Task.

And if you extended Profile, when you look at a list of your Profiles, the Profile Tasks would be included in that list.   That's because, in essence, they would be Profiles as well.   Real messy.

The fact that Profile Tasks extended from Profile would then show up in lists of Profiles would make things real ugly, real quick.   Reporting would be a pain.   You would need to always filter out the Profile Task class records to make any sense of your true Profiles."

And is a "Profile" really a Task?