Summary:
Both Spitfire and Microsoft Dynamics SL (DSL) need to know what user/employee is the project manager. Assuming your Project Managers are correctly configured in both systems (see Prerequisites below), Spitfire does its best to avoid scenarios where this needs to be maintained separately. Whenever a Spitfire user is added to a Project Team with a role with the Project Manager responsibility, Spitfire makes sure that the Project Manager is correctly on DSL‘s Project Maintenance screen. Spitfire assumes that this Project Manager overrides any other unless there are multiple PMs on the team, in which case DSL must be updated manually. If you remove the role with the Project Manager responsibility from a Spitfire user, the role is removed from the team list, but the user remains a team member unless removed specifically.
Legacy situations: When a project is created in DSL and the Manager1 field (often labeled Project Manager) is set to an employee that is an active Spitfire user contact, Spitfire checks to see if a Project Manager for the project already exists for this project. If Spitfire does not yet have a Project Manager assigned, Spitfire establishes the specified employee as the Project Manager in Spitfire and assigns that user the role responsibility of Project Manager for that project. If Spitfire already has at least one Project Manager assigned for the project, Spitfire ignores the change in DSL.
Additional Comments:
Prerequisites: In order for your Project Manager to be coordinated between the two systems, several details must be in order. Explicitly:
- The Project Manager must be an active employee in DSL‘s Project Employee Maintenance (PJEMPLOY).
- The Project Manager must be an active DSL User in Utility > User (USERREC).
- The Project Manager must be an active Spitfire User in Contacts > Contact (xsfUser).
- The Project Manager must have a Spitfire role with the Project Manager responsibility. (If multiple roles with this responsibility are available, Spitfire will default to the most commonly used; this default can be overridden using xsfConfig.)
You can verify this in the Contacts Dashboard by opening the Contact Details for the Employee. Verify that the Spitfire User and Microsoft Dynamics User checkboxes are both checked and that Employee field is filled in.
Some sites also use the PJPROJ Manager2 field (sometimes labeled superintendent, but usage varies). Spitfire can be configured to also set Manager2 when contacts with a specific responsibility are added to the Spitfire Project Team contact list. The GUID for the responsibility is specified by the implementer in an xsfConfig entry with KEY=MapManager2UCWorkKey. There is no default; manager2 is normally ignored.
Implementation Aid: To assist in initial implementation, the psf_SolomonPM stored procedure can be used to import Project Managers for existing projects. The stored procedure can be run from Query Analyzer as needed, but should be run after relevant employee user contacts have been created. The stored procedure takes a project mask as its only parameter — for example pass GC% to import all projects that begin GC.
KBA-01049; Last updated: March 5, 2020 at 17:45 pm;
Keywords: project manager role