Project task parent field shows empty because reference sys_id does not exist (broken reference)

[Vanshika Gupta]

We are seeing an issue in pm_project_task where the Parent field shows empty in the UI, but in the XML the parent field contains a sys_id, for example:

parent = c86566d1fb66e618ebd3f027aeefdc88 (display_value is empty)

When we try to open this sys_id directly in the browser or search it in the pm_project_task table, it returns “Record not found”. This indicates a broken reference where the parent sys_id stored in the child task does not exist in this instance.

These tasks were created manually (not via import or integration).

Has anyone faced a similar scenario where a reference field contains a sys_id that cannot be resolved?

What is the best way to:

1. Identify all such broken parent references in bulk?

2. Prevent this from happening during manual task creation?

3. Clean or correct the existing data safely?

Any guidance or best practices would be appreciated.

[Ankur Bawiskar]

@Vanshika Gupta 

it means that project is deleted but sysId is still there in that field, this is OOTB behavior.

hence it shows record not found.

Try searching in project table with that sysId and you won't find it.

💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏

[phil_bool_unifi]

Hey Vanshika.  Is it possible these tasks were generated by Template?  If so, has the 'parent' value been captured in the template?  That might happen if the task was originally generated as a child task within a project, but is now being used without that parent task.  To check this, head over to the 'Template - Project' module, and look at the template used, then navigate into the 'Project Tasks' list, and find the task there.

If you didn't use a template, here are a few other things to check:
Did you generate these tasks from the Project Workspace, the legacy Project Workbench, or the pm_project form/pm_project_task form?   The Project Workspace gives the most complete functionality.  Can you encourage adoption of this to reduce issues?

If you're generating these through an integration (eg a MS Project MPP import) then we can explore that, but this is not a typical issue. 

It's a long shot, but are you by any chance using a playbook to generate these tasks?  If so, that playbook's execution activities may have hard-coded sys_ids.

Lastly, have you got any business rules running on Project Task that might explain this?  Anything that updates the 'parent' record?

Resolving the data issues will be pretty straightforward, but finding the root cause is where the fun is going to be.