Presently, there are 2 tabs/pages for a project to log both Risks & Issues. However, there is no feature to convert an existing Risk to Issue which happen most of the times.

When this is available as a feature it becomes easier to see the trail from Risk to Issue and the mitigation's which taken/not taken which caused this risk to convert to an issue.

When this conversion happens the risk should be closed referring to the Issue ID so it also becomes intuitive for the users and will definitely help the project managers and the project teams to manage risks and issues more effectively.

Is there is a supported way for Microsoft partners to read local custom fields residing in Project Online? What appears to be the case is that CSOM is supported for Project Online, but PSI is not. Furthermore PSI gives access to local custom fields but CSOM does not. Thus there is no supported solution that allows read access to local custom fields in Project Online. I hope I am missing something here. It would be great to know if I am wrong or if there is a workaround. Failing that, it would be great to get an enlargement of CSOM to provide access to local custom fields. Please see attached summary of the MSDN documentation that leads to my suggestion here.

Jim

I would really appreciate a response to this request because I have customers who my company's applications to be able to read their project data from Project Online

In the Middle East, we can't show the Hijri Date in Project Center (Project Server 2010/2013/2016 with Arabic Language Pack) for the following:

1. Start Date, End Date, End Date and custom field with date type in PDP.
2. Timeline Date.
3. Gantt chart.
4. Views

If we changed the calendar regional setting in site setting, and go back to Project Center We got the below error:

"Sorry, something went wrong
This feature requires either a Gregorian calendar or a calendar that uses a Gregorian recurrence pattern.

Make sure your calendar is correctly set in:
https://mqassas.sa/_layouts/15/regionalsetng.aspx?Type=User

Also, check with your administrator to update the calendar in:
https://mqassas.sa/_layouts/15/regionalsetng.aspx

Unfortunately, it's not acceptable from our Arab clients, they want to show their Project List in Project Center with Hijri Date.

Does it make sense that a big product like Project Server didn't support Hijri Date?! Usually, we hear this sentence alot and we totally agree!

By the way, we can display the Hijri Date via Microsoft project but it's not an acceptable workaround, the customer wants to show his project list in Project Center with Hijri Date without opening each project one by one.

We can also customize custom reports via SSRS or whatever, but in this case, what's the value of Project Center with the customer who needs to use Hijri Date and Arabic MUI in Project Server.

I think this feature is very important to all Microsoft Arab customers around the world. We wish to be applied soon.

I think that the Resource Capacity/Engagement Heatmap is an enormously useful feature – I’ve built very similar reports for my customers in the past.

However, the current iteration of this report only shows capacity that is accounted for by engagements, and doesn’t account for any assignments that do not have proposed or committed engagements.

I think that enhancing this page to include information concerning assignments without corresponding engagements would be extremely valuable in two primary scenarios:
1) Identifying cases where resource capacity is being consumed outside of an engagement within the heatmap UX, especially considering that the stated intent of the engagements feature is not to block the PjM from making assignments without a committed engagement

2) Providing value to users migrating into 2016 who, for whatever reason, are not going to go back and create historical engagements or engagements for existing/future work that is already scheduled

Scenario for a multinational company with several business entities with only 1 Office 365 tenant.

• As for now, to access any new PWA instance (different from the default PWA instance) through the Office 365 interface,
1) Tenant administrator has to create a new Custom Tile in the Company Profile in the O365 Admin Center (as described in article "Add custom tiles to the My apps page and app launcher" https://support.office.com/en-us/article/Add-custom-tiles-to-the-My-apps-page-and-app-launcher-1136115a-75af-4497-b693-640c4ce70bc6?ui=en-US&rs=en-US&ad=US and "Customising the App Launcher– Part Two–Custom Tiles" https://epmsource.com/2015/08/02/customising-the-app-launcher-part-twocustom-tiles/)
2) End-user has to **manually** add the new tile to its App Launcher

• The default Project tile (pointing to the default PWA instance) will appear in the App Launcher as soon as you assign a Project Online license to the user. Most of the time, the end-user won’t have access to the default instance (because not part of the business entity associated to this instance), so having the default Project tile in the App Launcher will result in :
a. The end-user will be redirected to a Denied Permissions page, and would ask for permissions (per curiosity or per misunderstanding)
b. The default PWA instance administrators will receive a lot of permission requests

• The Custom tile (created in Office 365 Admin Portal) will be visible for the whole tenant, so every single user in the tenant will be able to pin the custom tile to its App Launcher [and maybe try to access and request for permissions they are not supposed to access to, which will also result in a lot of permission requests for every new PWA instance admins].

• The App Launcher can’t be customized in an industrial way (PowerShell scripts or else), so end-user will have to perform **manual actions** to unpin the default Project tile and pin the Custom tile created for the new PWA instance.

As a summary, Office 365 interface is not mature today to handle multiple PWA instances, for accessibility purposes.

An expected Project tile behavior should be as follows :
- If an organization has only one PWA instance, the Project tile is pointing to the default PWA instance.
- If an organization has multiple PWA instances, the Project tile is pointing to an intermediate page which displays all PWA instances that the end-user has access to (based on the defined permissions for the Private Site Collections).

Currently the currency setting is independent of the numerical value for costs. I would like to have project managers in different countries be able to plan and visualise project and resource data in their local currencies but then the roll up of data might show local currency (with other projects based on a different currency converted) AND have visibility of rolled up data with a global currency. At present there is only the option to have a single global currency (local currency setting is meaningless in the current version). And yes you can use custom fields to convert, but not when you are viewing resource usage for example. The numbers in the Ent Resource pool have to be based on a single agreed currency value.