External Activity Relationships

Introduction

The existence of external relationships does not necessarily represent an error. In many cases, they may reflect a valid planning decision. However, they require special attention because their behavior can change when the schedule is exported as an XER file and later imported into a different database.

xerPlanner identifies relationships between activities that belong to different projects. The purpose is to warn the user about links that may affect schedule interpretation, especially when the XER file is shared, imported into another environment, or reviewed without the related external projects.

Why external relationships can be a risk

As long as the linked projects exist in the same Primavera P6 database, external relationships may work normally. The issue appears when only one of those projects is exported and later imported into a database where the related projects do not exist.

In that scenario, external relationships may no longer exist as complete logic links, but Primavera P6 may preserve information associated with those external activities through External Dates. These external dates may act as implicit constraints on the imported schedule activities, affecting dates, float, and the critical path without being as visible as a traditional constraint.

The following screenshot shows an example related to external activities in Primavera P6. This type of information is important because it helps explain why an activity may be affected by dates or relationships that do not belong directly to the project being reviewed.

This can create several issues:

• distorted critical path;
• unexpected float calculations;
• activities constrained by less visible external dates;
• difficulty diagnosing why an activity does not behave as expected;
• differences between the original schedule and the imported schedule;
• confusion during audits, quality reviews, or claim analyses.

For this reason, even if an external relationship is valid in the original database, it should be carefully reviewed before sharing or importing an XER file into another environment.

How this analysis relates to the [e] mark

This analysis is especially important because it helps explain the [e] mark used by xerPlanner in other report findings.

When xerPlanner detects that a finding depends on an external relationship, it may add the [e] mark before the activity ID. This mark does not always mean the same thing in every analysis, but in general it warns that the interpretation of the finding depends on the existence of a relationship with another project.

For example, in analyses such as activities with no predecessors, no successors, open start, or open finish, an activity may be marked with [e] because it has external relationships that may be completing its logic. If the schedule is imported into a database where the external project does not exist, those relationships may disappear and the finding may be confirmed.

On the other hand, in analyses related to defective links, such as positive lags, excessive lags, lags with different calendars, negative lags, or Start to Finish relationships, the [e] mark indicates that the problematic relationship involves an external activity. If that relationship disappears when the XER is imported into a database without the external project, the finding may also disappear.

For this reason, this section of the report allows the user to review the details of those external relationships: which activities are involved, which external project they belong to, and what type of relationship exists between them.

What xerPlanner shows in this analysis

xerPlanner lists relationships where the predecessor activity and the successor activity belong to different projects within the XER file.

The report shows the activity from the analyzed project, the related activity, the relationship type, and a reference to the external project. This information helps determine whether the external link represents a real interface between projects, an inherited dependency, an accidental relationship, or a condition that could create issues when importing the schedule.

This analysis does not aim to state that every external relationship is incorrect. Its purpose is to provide visibility over a condition that often goes unnoticed and may have relevant effects on schedule logic.

Best practices

The first recommendation is to review whether the external relationships are truly necessary. If the schedule must work independently, its main logic network should ideally depend on internal activities rather than projects that may not exist in another environment.

When an external relationship is intentional, it should be clearly documented. This is especially important in contractual schedules, contractor schedules, integrated programs, or XER files that will be shared with third parties.

Before delivering or importing an XER file, it is advisable to review the external relationships identified by xerPlanner and decide whether they should be kept, replaced with internal milestones, documented, or removed. It is also recommended to review External Dates after importing the file into a new database, to verify whether external dates are affecting the schedule calculation.

Conclusion

Relationships with external activities can be useful in integrated Primavera P6 environments, but they can also create significant risks when schedules are exported and imported through XER files. Their presence should not automatically be interpreted as an error, but it should be known, reviewed, and documented.

This analysis helps identify which external links exist in the schedule and supports the correct interpretation of the [e] mark used in other xerPlanner findings. Reviewing these relationships improves schedule traceability, reduces surprises when importing XER files, and supports better decisions before sharing, auditing, or using the schedule in another environment.