MS Project Unique ID is the permanent numeric identifier Microsoft Project assigns to a task within a project file. Task ID, by contrast, represents the task’s current position in the schedule. If you insert, delete or move tasks, Task IDs can change. The Unique IDs of the surviving tasks remain constant.
For day-to-day schedule navigation, Task ID is usually easier to read. However, Unique ID is the better reference for comparing schedule versions, joining recurring exports and tracing a task after the schedule structure changes. Neither field should automatically replace a controlled activity ID, work breakdown structure (WBS) code or contractual schedule identifier.
MS Project Unique ID: What It Actually Identifies
Microsoft Project assigns a Unique ID whenever it creates a task in the current project. The field is read-only, so a scheduler cannot renumber it to match a contract line item, control account or preferred numbering convention. Microsoft’s Task.UniqueID documentation also identifies it as a read-only numeric property.
The Unique ID belongs to the task record, not to the row where the task currently appears. Therefore, the value follows the task when the scheduler moves it to another part of the outline. Summary tasks, detailed activities and milestones all receive task identifiers because Project treats each one as a task object.
Unique IDs often contain gaps. For example, a schedule may display Unique IDs 101, 104, 118 and 125 on consecutive rows. That pattern does not indicate corruption. It usually reflects prior additions, deletions and restructuring.
The word unique also needs context. The value is unique within the project, but it is not necessarily unique across unrelated project files. Task 45 in one file and task 45 in another file can both have Unique ID 45. Consequently, an external database should normally use a project identifier plus the task Unique ID as a composite key.
How Task ID Differs from Unique ID
The Task ID field is the familiar number shown at the left side of most task views. It identifies the task’s present location in the task list. Microsoft’s Task.ID documentation states that the ID changes when a task moves to a new location and recommends Unique ID when a constant task reference is needed.
The practical differences are straightforward:
- Task ID reflects current position. It can change when tasks are inserted, deleted or physically moved.
- Unique ID reflects task identity. It remains associated with the surviving task within that project.
- Task ID is convenient for navigation. A reviewer can quickly find Task 250 in the current file.
- Unique ID is better for traceability. It can help match the same task between related schedule versions.
- Both fields are application-controlled. They are not suitable for a manually governed numbering scheme.
Project also distinguishes these fields in its available fields reference. The reference describes ID as an automatically assigned identifier and Unique ID as the number designated when a new task, resource or assignment is created in the current project.
A simple example
Assume the fictional Falcon Sensor Upgrade integrated master schedule contains the following activity:
- Task name: Complete Critical Design Review package
- Task ID: 42
- Unique ID: 184
The scheduler later inserts five activities above the design review package. Its Task ID becomes 47, but its Unique ID remains 184. Next, the scheduler moves the activity beneath a different WBS summary. The Task ID changes again, while Unique ID 184 continues to identify the same task record.
However, suppose the scheduler deletes the activity and creates a new row with the same name, dates and logic. Project treats that row as a new task and assigns it a new Unique ID. Matching names do not restore the deleted task’s identity. This distinction matters because an IMS can contain legitimate duplicate task names.
When Schedulers Should Use Task ID
Task ID remains useful for routine schedule work. It provides a short, visible reference that corresponds to the current version of the file. During a working session, a scheduler can tell a control account manager (CAM), “Review Task 347,” and both users can navigate to the same row.
Task ID is also the identifier displayed in the standard Predecessors and Successors fields. If the schedule remains open and the team is discussing its current configuration, those references are usually adequate.
Use Task ID for:
- Finding a task in the current schedule version
- Reviewing ordinary predecessor and successor entries
- Discussing a task during a live schedule review
- Temporary analysis that does not need to survive restructuring
- Explaining where a task currently appears in the outline
However, avoid placing Task ID in meeting minutes, corrective-action logs or long-lived external records without also recording the task name, WBS and schedule version. A future insertion or deletion can cause that number to point to a different activity.
When Unique ID Provides Better Traceability
Unique ID becomes valuable when the reference must survive normal schedule maintenance. For example, a program-controls analyst may export schedule data every accounting period. If the analyst joins the current export to the previous export using Task ID, inserted activities can shift the IDs and create false matches. Unique ID offers a more stable key for tasks that remain in the same evolving project file.
Common uses include:
- Comparing recurring exports from related versions of a schedule
- Supporting macros, queries and automated quality checks
- Tracking open schedule-review comments against specific tasks
- Investigating whether an activity moved within the WBS
- Identifying dependencies through Unique ID Predecessors and Successors
- Supporting traceability during controlled schedule changes
This stability supports good program-controls practice, but it does not create configuration control by itself. Teams still need documented naming, coding, status and change-control procedures. For broader context, see how to maintain baseline traceability.
Unique ID Predecessors and Successors
Microsoft Project includes Unique ID Predecessors and Unique ID Successors fields. These fields display logic relationships by Unique ID rather than the current Task ID. Microsoft’s Unique ID Predecessors reference confirms that the field can include the dependency type and lead or lag value.
For example, an entry of 184FS+2d means the task has a finish-to-start relationship with the task whose Unique ID is 184, plus two days of lag. If the predecessor moves elsewhere in the task list, its Task ID may change. The Unique ID relationship continues to point to the same task.
These fields can help with technical analysis and exports. However, most schedulers should still build logic with Project’s normal linking tools rather than manually typing large lists of Unique IDs. Manual entry increases the chance of selecting the wrong task or relationship type.
How to Display Unique ID in Microsoft Project
To display the field in a task view:
- Open a task view such as the Gantt Chart or Task Sheet.
- Insert a new column.
- Select Unique ID from the field list.
- If needed, also insert Unique ID Predecessors or Unique ID Successors.
A useful review table may include ID, Unique ID, WBS, Name, Duration, Start, Finish, Predecessors and Total Slack. That combination lets the reviewer distinguish the task’s current location from its persistent internal reference.
Before a customer delivery, consider including Unique ID in a working quality-control view even if it will not appear in the final customer table. It can help the scheduling team resolve comments and compare revisions. A broader IMS customer-delivery review should also examine logic, constraints, calendars, progress and baseline integrity.
Unique ID Is Not a Controlled Activity ID
Program teams sometimes treat Unique ID as the schedule’s official activity number. That approach has limits. Project controls the value, users cannot assign meaningful numbering, and unrelated files can contain the same numbers.
A controlled activity ID often needs to follow program rules. For example, the identifier may encode a WBS element, responsible organization or schedule level. In that case, use an approved custom text field, outline code or another governed coding field. Define ownership, formatting and uniqueness rules in the scheduling procedure.
Do not confuse Unique ID with a WBS code either. WBS and outline numbers describe hierarchy. Unique ID identifies the internal task record. Moving a task may change its WBS or outline position while its Unique ID remains constant.
Microsoft Project also exposes a read-only task globally unique identifier through the Task.Guid property. If an integration requires a globally unique technical key, evaluate the GUID and the receiving system’s requirements. Even then, retain a controlled business identifier when users need a recognizable activity code.
Implications for IMS and EVMS Workflows
For an integrated master schedule (IMS), stable task identity helps analysts follow activities through status cycles and structural changes. This becomes especially useful in large schedules where Task IDs shift frequently. Teams using Microsoft Project for integrated master scheduling should understand both fields before designing exports or automated checks.
Unique ID does not establish the Performance Measurement Baseline (PMB), authorize a baseline change or satisfy a contractual reporting requirement. It is a Microsoft Project data field. Contractual identifiers and delivery formats depend on the contract, applicable data item descriptions, agency direction and program tailoring.
In addition, Unique ID does not protect baseline history if a scheduler deletes and recreates tasks. Deleting the original task removes that task record and its associated task-level history from the working file. Therefore, schedulers should modify existing tasks when appropriate and process substantive baseline changes through approved change control rather than rebuilding rows merely to obtain clean IDs.
Common Mistakes
- Using Task ID as a permanent reference. The number can later identify a different row.
- Assuming Unique ID is unique across every project. Pair it with a project or file identifier in external datasets.
- Renumbering work to make Unique IDs sequential. Gaps are normal and do not require correction.
- Deleting and recreating tasks to clean the schedule. The replacement task receives a different identity and may weaken traceability.
- Using task names as database keys. Names can change or appear more than once.
- Treating Unique ID as a contractual activity code. Use the identifier required by the program’s approved scheduling and reporting rules.
- Joining independent files by Unique ID alone. The same number can represent unrelated tasks in different projects.
Frequently Asked Questions
Does MS Project Unique ID ever change?
It remains constant for the same task within the project, even when the task moves. However, deleting the task and creating another task produces a new task record. Copying work into an unrelated project also should not be treated as preserving the original file’s identity.
Can I edit or renumber the Unique ID field?
No. Project controls the task Unique ID, and the corresponding object-model property is read-only. Use a custom field if the program needs an editable activity numbering convention.
Should predecessor logic use Task ID or Unique ID?
Project’s standard Predecessors field uses Task IDs and is appropriate for normal schedule development. Unique ID Predecessors can provide a more stable display or export reference when the task list changes.
Which field should I export to an external system?
Export Task ID when the receiving process only needs the current row reference. Export Unique ID when matching recurring versions from the same schedule lineage. For durable integration, include the project identifier, Unique ID, controlled activity ID, WBS and task name rather than relying on one field alone.
The Practical Rule
Use Task ID to locate a task in the schedule you have open. Use Unique ID to track the same task as that schedule evolves. Finally, use a governed custom activity identifier when a program, interface or customer requires a stable business code.
Keeping those purposes separate prevents false version matches, broken comment logs and confusion during schedule reviews. More importantly, it preserves the distinction between Microsoft Project’s internal task identity and the identifiers your program controls.