KBA-01757: Project ID Migration and Locked Projects


Why does the project ID on a series of documents change at the same time?


Spitfire sfPMS includes a Project ID cascade feature. If you change the Project ID on, say, an Invitation to Bid, then the Project ID on all the attached Bid Packages will also change. But it does not stop there! The process contines: the Project ID on all the RFQs attached to the Bid Package will also change. And if any of the RFQs were awarded into a Subcontract /Commitment, then those Project ID are also changed. And if any of the Commitments have included CCO or Pay Requests, etc.

In addition to the documents themselves, files attached to the documents are also migrated.

This feature is a great time saver in certain common scenarios:

  • Using the Change Project ID dialog
  • Winning a bid and creating a project
  • Branching one project into two

But there are also scenarios where you might want data to be immune to any change of the Project ID. The most common scenario is a template project (see below).

Additional Resources

  • KBA-01153 includes the ProjectConfig | ProjectLocked rule – this can identify the ID pattern “reserved” for template projects to protect them from cascading changes.
  • KBA-01154 includes DocTypeConfig | ProjectCascade (that indicates which document types can start a cascade) and DocTypeConfig | ProjectLocked that indicates which documents types are immune to cascade (such as Project Setup).