Delegation in Project Online: what's wrong??

4 years ago, I wrote an article about the delegation limitations and it has reached a great number of views. I guess this is because the delegation feature is (I should say was) intensively used by administrator for daily support and security model use case testing.

However back to May 2016, we noticed a strange behavior while running delegation sessions. Starting a delegation session for a user with limited access (team member for example), we were seeing more projects than we were supposed to. As usual, Brian Smith reacted promptly and published an article to explain this unexpected behavior. I didn't update my initial article at this time, and I now feel like I should write a short post about it since I still see this question on the TechNet forums and from some on my customers, so I think that this change in the delegation feature is still not completely known and well understood.

Basically you'll see this unexpected behavior if the delegate user is a global administrator (O365 admin or Site Collection admin). Here the reason of the change, with Brian's words: "The reason for the change is that in Project Online customers were accidentally locking themselves out of PWA by removing all their PWA administrators – and then the only way to make a user an admin again was to open a support call". To avoid this frustrating situation where the admin is locked into a delegation session, this restriction was created.

The workaround is unfortunately not magic: you simply have to use a session (not delegated) of a user to test the security model. 

PowerBI : manage different project calendars in your dahsboards.

Following my previous article talking about how to manage your calendar working time as a parameter in PowerBI, I had an interesting comment from my fellow colleague Xavier Trottin. Xavier has a similar role as me, but works most of the time with larger organizations. Meaning that they often (always) have different project calendars because they are managed in different countries with specific working week hours.

Thus my previous method doesn't work. It would require having as many parameters as calendars. 

The way Xavier proposes to manage this use case is to retrieve the minutes per day, which is a data based on the project calendar and attached to each project. The issue is that this data is not accessible in the standard OData reporting PROJECTS table (/_api/projectdata). You have to collect it from the /_api/ProjectServer/Projects table.

Here are the steps to perform to go further in your deployment industrialization.

1- Create a new query. In the source step of the new query, access the table mentioned above. Note that since the PWA url parameter goes until /PWA, you don't have to create a new parameter.

2- Select the ID and minutes per day columns. Note that you can find here a lot of useful information, such as "ischeckout" or the last saved date.

Then you'll get the query output as following, with the project ID which will be the key of the merge and the minutes per day (420 in my example for 7 hours/days).

3- Merge queries. From the standard PROJECTS query, merge it with the newly created query. You'll have to select the project ID from both queries to merge the tables.

4- Expand the column. I'm not really sure if this stage is mandatory but it allowed me having the minutes per day column in the standard PROJECT table in addition to the merged query. You do not need to include the ID column since it is only used for the merging step.

5- Use the new measure in the formulas. Back in the desktop client, for the project duration in days in my example, I divide it by the minutes per day multiplied by 60 (to get hours).

Et voilà! Thanks again to Xavier for the tip. And remember that those improvments have a considerable added value since you do it on one report and you can deploy it for any customer.

PowerBI : manage the working time as a variable in your dashboards!

In PowerBI reports, I usually propose a set of dashboards including standard indicators. On a portfolio dashboard such as the one below, you'll always find the duration, baseline, variance, etc...

By default, any data related to time unit in the reporting database is expressed in hours. When you talk about work, it might relevant, but duration are most of the time more comprehensive in days.

In my first reports, I used to create a new column with a formula dividing the duration by the number of hours in a working day.

When you have one major Project deployment per year, this can be a suitable solution. However I personally saw the change in our Project consultant job: with Project Server, we used to do major deployments which could take months and even years. Now with Project Online, since you don't manage the infrastructure part, deployments are much more simpler and quicker. Moreover much more organizations are interesting in deploying Project Online since it is now opened also to smaller companies (less licensing fees). Therefore we are doing a large number of smaller deployments.

All that to say that with this new paradigm, we do need to industrialize our deployments and particularly PowerBI reports deployments. In the usual use cases where the working days can be different in all organizations, the method described above can be time consuming.

So here is the solution: set the working time as a variable.

1- In the PowerBI Query Editor, select "new parameter". You can create a new parameter "hrs_day" with a list of values (7, 8, etc...) and select the current value for the company you're deploying Project Online.

Note that I already have the PWA tenant URL as a parameter.

2- In the dataset where you need to convert hours into days (Project dataset in my example), add a custom column calling the parameter.

3- Back in the desktop client, select again the Projects dataset and select the measure having the manual calculation (.../7). You can also create a new column. Replace the division by 7 by the new parameter.

Here is how to manage working time as a parameter in your PowerBI dashboard. This will optimize your report deployment for new customers and make you reporting toolbox more efficient.