The Time Tracking Stalker - RM workflow process automatically sends an email to Resource Managers for each one of their resources that have not submitted their timesheet for a prior open time period, thus informing the RM if their resources are submitting their timesheets on time. Project Managers will also benefit since the notifications will help to ensure that time is being posted against their projects in a timely manner, helping to provide them with an accurate view of time expended on the projects.

The Timesheet Approval - RM and PM process is an auto-start process that begins once the resource submits his or her timesheet. This process provides a checks-and-balances style to ensure that all resources entering time have entered the 40 hours. Once the timesheet is submitted, the process will lock the user’s timesheet to prevent editing. The process will then select the next action based on three different factors:

1. The timesheet has less than 40 hours.
2. The timesheet has 40 or more hours.
3. The resource’s availability is less than 8hrs/day.

If the user has submitted a timesheet with less than 40 hours, then the process will email the user informing him/her of issue, unlocks the timesheet, and changes the status to “Returned”. If the user has an availability of less than 8hrs/day or the timesheet has 40 or more hours, then an action item will be sent to the resource manager informing him/her of the timesheet. If the resource manager (RM) AND project manager (PM) approves the action item, then the process will approve the timesheet and unlock the timesheet. However, if the RM or PM selects “Return” on the action item, then the process will return the timesheet, mail the user that informing him/her that the timesheet has been returned, and unlock the timesheet.

The Move Role to Team/Assignment process takes the role from the resource object and pushes that information into the team and assignment objects when the role is NULL on the team and assignment objects. This happens normally, assuming a resource has their primary role populated.  This process is needed if a resource or set of resources were added to projects without having their primary role filled in.

The Grant Team Project Edit Rights workflow allows a project manager to grant Project – Edit Management rights to all users staffed on the project. This workflow saves not only the project manager time by allowing all users on the project to update information, but also saves the administrator time from granting each resource these rights individually. The process will also remove any rights from members that have been removed from the project.

Based on the pre-determined schedule frequency, this job will send an email to Project Managers that have a project meeting the criteria of: project(s) are active and scheduled finish date is less than the current date. This serves as a reminder to Project Managers to keep their schedules true. The contents of the email include a message indicating the project manager has at least one project meeting this criteria and a table indicating the Project ID, Project Name and Scheduled Finish Date.

The Project Compliance Stalker – PM sends an email to Project Managers (and also their managers if so desired) at a set interval to alert them to project compliance issues. Areas of compliance that are reviewed include: stale project tasks (stale = past due date), late issues and risks (past due date) and late status reports.

When a task is marked as complete the process looks to any tasks that are dependent on the newly completed task.  If a task is marked as “Not Started” and all of the dependency tasks are marked as complete then the process will change the task status to “Started” and email all resources that are assigned to the task that has started. The process notifies resources that a task is ready to start and saves the project manager the manual effort of updating dependent tasks.  NOTE:  The process relies on task dependencies and is most useful in those environments where task dependencies are managed.

This process, Shift Project Dates, helps Project Managers change an entire Project / Idea’s dates to a new start date.  Once the three attributes are added to the Idea /Project Views, the PM can trigger the process by entering a date in the New Start Date field and checking the Shift checkbox.  The process runs automatically on Save. The process calculates the date difference between the original Start Date and New Start Date then shifts all Allocation, Task, and Assignment dates by the calculated difference. For example, if a Project is set to begin on January 1^st and needs to be pushed to a February 1^st start date, the process first determines that there are 31 days between the original start date and the new date.  Next the process increases the start date for each Task, Allocation and Assignment by 31 days. NOTE:  The process will shift Allocation dates regardless of resource restrictions such as a Termination Date or non-working time as marked on their calendar.  The Team page will reflect the Available Start and Finish as shifted by the process, but the Allocation hours and % will take unavailable time into account.  For example, if a shift process sets the start date for a resource to be after their date of termination the dates will change by the date difference, but the Allocation hours will correctly be calculated as zero.

This notification process sends an email to the Manager of an investment (Project, Application, Idea, etc) when the resource assigned to the team has been hard booked.   The process should be scheduled to run on a daily basis as the logic in it looks to all resources where their Booking  Status has been changed from Soft to Hard on the day that the process is run.  It compares the audit trail date change field to the system date. If the process is not scheduled to run daily no notification will occur on hardbookings from previous days.

This process pulls in the total hours tracked, by resource, by task, for a given project for the weekly time period that ended. The information is sent to the Project Manager listed on the project. This process can be scheduled via the Execute a Process job.

This process updates the team, assignment and timesheet roles with the primary role where they do not match. This way, the PM can push all roles to team and assignment for that project before they do a cost plan.

The interface runs using a MS Excel template called Project Allocation Upload that will be distributed to users.

1. Configuration
   1. A master object called Allocation Upload Files will be created.  The object will contain a required attachment field on the create page that will receive the Project Allocation Upload MS Excel file.
   2. A new sub-object called Allocation Upload Records will be created.  This object will contain the fields necessary to receive the data rows from the Project Allocation Upload template.
   3. The master object will store the file level data while the sub-object will store the rows that belong to the file.
   4. Users must be granted security to view and edit the master and sub-objects in order to run the upload process.
2. Project Allocation Upload Template
   1. The Project Allocation Upload template must remain static.  Any changes other than creating additional time periods or additional rows will cause the process to error.
   2. Only the Project Allocation Upload template can be used to load records to the new objects.
   3. The Project Allocation Upload will only accept months across the x-axis in the format DD/MM/YYYY.  The month headers must appear in the first row of the template and contain the first day of the month.
   4. The template must be distributed to the users that will be using the upload functionality.
   5. Users will be required to enter an Investment ID and Resource ID so the process can correctly identify investments and resources to upload the allocation hours against.
   6. A Staff OBS is not required but can be populated by users to have the data uploaded into CA PPM.
   7. The owner of the Project Allocation Upload template is responsible for providing users a valid list of Staff OBS Units.
   8. Investments will not be created through the interface. As such a valid Investment ID must be provided.
   9. Resources can be added to the investment team through the interface.  If a valid Resource ID is provided the resource’s allocation will be updated if the resource already exists on the investment.  If the resource does not already exist on the investment the resource will be added to the team along with the allocation hours.
   10. The Project Allocation Upload template will accept hours, not allocation percentages.  Because CA PPM stores allocations as percentages of a resource’s availability the upload process must convert hours to a percentage.  As a result small rounding errors may occur in the neighborhood of .01 hours per month.
   11. Resources cannot be removed from investment teams through the interface.
   12. The Project Allocation Upload template will support allocation uploads to different instances of the same role on the same investment as long as different Staff OBS units are provided.
       1. If multiple instances of the same role are assigned to the investment with the same Staff OBS the process will not know which instance of the role to upload the hours to.  In these cases the process will consider these records as invalid.  The PM will need to manually remove one of the instances or upload the hours manually..
       2. If multiple instances of the same role with the same Staff OBS unit are assigned to the same investment in the upload template the monthly hours will be totaled by investment, by role, by Staff OBS.
   13. The allocation template will follow the format in the screenshot area.
3. Process
   1. To initiate the Allocation Interface a user will create a new Allocation Upload File instance, attach the Project Allocation Upload Template, and save the record.  The file attachment field is an “enter-once” field, meaning that once a value has been set it cannot be changed.  If a user wishes to upload another field they will create a new record.
   2. After the file has been attached the user will be presented with two check box fields, one to Validate and one to Validate and Upload.  Checking either or both options will initiate the process.
   3. The process will first determine if any sub-object instances exist for the file.  In other words, do any records already exist in the Allocation Upload Records sub-object pertaining to the newly uploaded file.  If there are no records in the sub-object the process will use the uploaded file and read its contents into the sub-object.  If errors are encountered during the file read they will be written to the process console, the process will throw an error, and end.
   4. Next, records will be validated.  Only the sub-object instances that belong to the master object will be validated.  Records belonging to other master object instances will not be validated or processed.  All records in a status of Ready for Processing, Failed Validation, or Xog Load Error will be validated.  Records will fail validation if an investment is not found corresponding to the investment ID provided, a resource is not found corresponding to the resource ID provided, or the date provided is not valid, or a provided Staff OBS does not yield a match.  Records that fail validation will be flagged as invalid along with a description as to why they failed validation.  Records that pass validation will be flagged as Ready for Processing and locked.  The sub-object instances can be exported to excel if further analysis is required.  If the Validate & Upload option was not selected the process will end here.
      1. Regarding the Staff OBS.  Only one OBS can be designed as the OBS that the interface will use to validate the Staff OBS records.
      2. The Staff OBS value from the template must match against the name of an OBS node in the designed Staff OBS.
      3. If the Staff OBS value matches against multiple nodes in the Staff OBS the record will be flagged as invalid as the process will not know which node to use.
   5. If the Validate & Upload option was selected the process will continue and any valid records will be xog’ed into the investment team.  The xog will be executed as the user that initiated the process so any security rules enforced by xog will be respected by the process.
   6. Successful records will be flagged as Processed Successfully in the sub-object and remain locked.  Records that did not load successfully, due to a xog error or security limitation will be flagged as Xog Load Error, unlocked, and updated with a description containing the full xog output.
   7. Records that failed validation or failed the xog load can be manually edited and revalidated, and attempt to be uploaded again.  Subsequent runs of the process will not read in data from the file, but rather process only sub-object instances that currently exist.