Dynamics 365 version 9.0.2, web client
Granting access to the Schedule Board and limiting visibility of Bookable Resource Bookings to a Bookable Resource are questions that have turned up in the community. I decided to investigate these issues and using the Project Resource Security Role is a good starting point as it doesn’t allow access to the Schedule Board by default in Dynamics 365 Project Service Automation. The error that is shown is pretty self explanatory: Read privilege to the Schedule Board Setting entity is missing. This entity can be found under the Custom Entities tab on a Security Role. As I’m going through the steps of granting access and visibility, I’m using an instance that has one Business Unit in use. My test user John Doe is in that Business Unit and is not a member of any Team.
Granting access to the Schedule Board
When the access level to the Schedule Board Setting entity’s Read privilege is set to User, we gain access to the Schedule Board. With this access level the Schedule Board can be viewed in the Daily, Weekly and Monthly views. The Hourly view will not work at this point as by default the access level to the Booking Setup Metadata entity’s Read privilege is set to User. Below is a photo of the Schedule Board when the Hourly view is accessed with an access level of User to the Booking Setup Metadata entity’s Read privilege.
When the access level is changed to Business Unit the Hourly view can be accessed. Notice that the user will now see all Bookable Resources and Bookable Resource Bookings on the Schedule Board.
Changing access levels for entities on the Service tab
The Service tab holds entities related to Bookable Resources and Bookable Resource Bookings. By default all these entities have an access level of Parent: Child Business Unit (later referred to as PCBU) to the Read privilege. Remember that in this example the Project Resource Security Role is used.
When the access levels to the entities shown above are altered, we can see some changes in the Schedule Board’s behavior. Remember that so far only the Schedule Board Setting and Booking Setup Metadata entities have been worked on and we can see all Bookable Resources and Bookable Resource Bookings as the photo displaying the Hourly view of the Schedule Board shows.
1. Setting the access level on Bookable Resource’s Read privilege to User displays an empty Schedule Board.
2. Setting the access level on Bookable Resource Booking’s Read privilege to User displays all Bookable Resources but no Bookable Resource Bookings (access level changed back to PCBU after step 1). Notice that my demo user John Doe can’t see his own Bookable Resource Bookings with this access level at this point.
Seeing Bookable Resource specific Bookable Resource Bookings on the Schedule Board
We can summarize that based on the previous steps we are able to access the Schedule Board and make the Hourly to Monthly views visible. What we are still missing is the ability to limit the Schedule Board views to only show Bookable Resource Bookings for test user John Doe. The reason for the behavior witnessed in the previous steps 1 and 2 is actually quite logical: John Doe is not the owner of his Bookable Resource record nor is he an owner of a Bookable Resource Booking. The owner of a Bookable Resource record is the person who has created the record and the owner of a Bookable Resource Booking is the scheduler who has created the booking (i.e who has for example dragged and dropped a booking to a resource on the Schedule Board).
When we set John Doe as the owner of the John Doe Bookable Resource record and set the access level on Bookable Resource’s Read privilege to User, we can see some changes in the Schedule Board’s behavior. As we can see from the photo below, John Doe can now only see himself on the Schedule Board. He can also see all the Bookable Resource Bookings where he is the Bookable Resource.
For a comparison of the different Security Roles in PSA, be sure to check my older blog post here.
All my blog posts reflect my personal opinions and findings unless otherwise stated.