In a previous post we detailed some of the improvements that we made to timesheets in Project Web App (PWA) 2013 targeted at end users. While end user improvements are great because they impact the largest audience for PWA we didn’t want you to think that we’d forgotten the administrators and developers either!
To be fair, some of these improvements are just as much for the end users as they are for the administrators in making life easier for everyone, but who doesn’t like a win-win?
A common request for PWA timesheets is the ability to support lines on a timesheet that are not related to a specific project but aren’t personal tasks either. Some examples might include work spent on service tickets or ongoing maintenance activities. In PWA 2013 we have expanded the concept of “Administrative time categories” to encompass this form of work by allowing for multiple lines to be added to an administrative category on each timesheet.
In the PWA settings interface for configuring administrative time categories note that an additional checkbox for “Allow Multiple Lines” has been added. In this example I have configured a “Service Tickets” category for the folks in my engineering department to use when they need to track time against a service task that is not specifically related to a project.
On the end-user side note that “Administrative Time” has been renamed “Non-Project Work” to help relay the broad nature of the lines that might fall into this bucket. If, as an end-user, I wanted to track time that I spent resolving a service ticket I can now do so by adding a new Non-Project line to my timesheet:
This brings up a dialog where I can select the category and provide a description:
Note that the previous administrative lines like Vacation and Sick Time can still be added by selecting the appropriate category. Because neither of those categories have been enabled for multiple lines, the behavior when adding/re-adding lines will be consistent with previous versions. We decided to differentiate categories that should have multiple lines from those that should not to avoid confusion for customers that don’t want to make use of the new multi-line experience. Also, you may only want to allow users to have one vacation-related line per time period while allowing for multiple lines in other categories.
Now I’ve entered in the ticket number for which I need to track time and can click OK to add it to my timesheet.
You can see that I have two tasks (for tickets 3423 and 3437) in my timesheet now, both in the Service Tickets category. From my previous post on end-user timesheet improvements you may recall that administrative lines are now carried forward to new timesheets for future periods. This new behavior supplements the Non-Project work scenario by making these service ticket lines automatically available in future periods without any additional work on my part if I need to continue tracking work against them.
While this example demonstrated adding lines to the timesheet manually, you might achieve a tighter integration with a 3rd party ticketing system through the use of event handlers to automatically add lines for assigned service tickets to the user’s timesheet and then validate and import line data back into the ticketing system on timesheet turn in/approval. Later in this post I’ll detail some improvements to the event handlers we’ve made that will help support this.
Filter Administrative Categories by Department
In the previous example you might have noticed another addition to the administrative time category configuration page allowing for departments to be related to administrative time categories.
This is in answer to another common request which was that we allow for filtering of administrative categories for customers with large organizations and lots of administrative categories of which only a subset are relevant to a particular individual user. In 2013 you can specify the department for which the line is available to be added to the timesheet (no specified department means everyone can see the category). Note that more than one department can be specified. In the example pictured the Customer Travel category will appear for Executives and Marketing while the Service Tickets category will only appear for members of the engineering department.
It’s important to note that the filtering of administrative categories is not a security measure, but just a simplification to the UI. It only impacts the categories that end users see in the dropdown for selecting an administrative time category when they are adding an administrative line to their timesheet. Users that have previously added a category to their timesheet will not see that line disappear if the configuration changes in a way that would make the category no longer available for adding to their timesheet (for example they are placed in a different department or their department is removed from the administrative category). Also, previous timesheets will not be impacted (even if they are recalled) to keep historical timesheet data consistent.
Default View Configuration
As part of our effort to simplify the end-user timesheet experience we found that many customers wanted the ability to pre-configure the timesheet view so that end-users did not have to pay the “start-up cost” of configuring the default grouping and sorting options for their timesheets. In 2013 we’ve added an additional section to the timesheet views configuration page allowing administrators to pre-configure additional view settings for users:
Note that end-users still retain the ability to customize their view further if they so desire, and the settings entered here for a particular view will not override any end-user customizations. Also, view configuration for historical timesheets will not be impacted by these settings.
Timesheet Managers List
When not using fixed approval routing, timesheet users have the ability to select the next account to which their timesheet should be sent when turning it in. Also under this configuration interim approvers (users without the “Approve Timesheet” permission) must select the next account to send the timesheet to when they make an interim approval. This feature is designed to support scenarios where the regular timesheet approver may be out of the office or any other scenario where a user must submit their timesheet to a different approver each period.
In previous versions the list of users to whom a timesheet could be turned in was created based on users who were granted the “Accept Timesheet” permission, but security model changes in 2013 have made the “Accept Timesheet” permission obsolete. In order to populate the list of users to whom timsheets can be turned in (called “Timesheet Managers”) new administrative UI has been created. In PWA Settings under the Time and Task Management heading there is a new link to “Timesheet Managers” which leads to the page where Timesheet Managers can be specified:
For customers who have more advanced configuration needs there is a Project Server Interface (PSI) method available for this list. You can find further documentation on this interface available at the following links:
Better Eventing Model
A very common request for timesheets in Project Web App is additional workflow functionality for the timesheet approval process. While we were not able to bring the full power of Windows Workflow to timesheets in 2013 we have made some incremental improvements that should unlock basic routing and messaging scenarios using event handlers.
To enable dynamic routing of timesheets to different users depending on business logic you can now set the ApproverUID argument from both the OnReviewing and OnSubmitting event handlers for timesheets to dynamically specify the account that the timesheet should be routed to.
To enable better messaging you can now set the CancelReason argument for the OnUpdating and OnSubmitting event handlers and the message will be passed back to the user in the timesheet UI. This enables you to specify business logic that validates submitted data with a message passed back to the end-user informing them of any changes they need to make for the timesheet to be successfully submitted.
Consider a scenario using these updates in combination with the non-project work lines detailed previously. When a user turns in their timesheet logic could validate that each of their non-project work lines in the Service Ticket category matches an actual service ticket in a 3rd party support system and automatically rejects the timesheet submission if the line cannot be matched. Using the CancelReason argument the user can be informed of the line(s) that need to be updated. Upon successful submission the timesheet is approved by the user’s immediate supervisor, but because of the additional non-project work lines it must also be approved by an IT administrator who can validate the Service Ticket accounting. Using the ApproverUID from the OnReviewing event handler the timesheet can be dynamically routed from the user’s immediate supervisor to the appropriate IT administrator to support this scenario.
Finally we have made a number of backend improvements to providing better performance to the timesheet interface. Most importantly the timesheet save and turn in processes have been removed from the queue and now run synchronously providing both better performance and immediate user feedback for save and turn-in operations. Project Web App administrators should note that backend troubleshooting has been simplified by this change. Now users will immediately be made aware of any issues with their timesheet processing and administrators can use the ULS log to find recorded messages instead of having to track down failed queue jobs.
Thanks for reading and we really hope that you find the improvements that we’ve made to this feature in Project Web App 2013 helpful and valuable. As always we appreciate your feedback as we consider ways to make this feature even better in the future!