• Ability to hide Schedule Board tabs launched from the RSO optimization schedule

    When you open the schedule board using the button on the optimization schedule, a new tab is generated, this might give you quite a number of tabs. Hiding them works (e.g. by only assigning them to a dummy user) , however if you now try to open them again from the optimization schedule, you end up with an empty browser tab, the board doesn't load. Suggestions: Even if the SB is assigned to someone else, if you have access to the optimization schedule, you should also be able to open the associated board.

  • Confirm changes before saving the schedule board settings

    We often see users accidentally changing settings on a schedule board, affecting other user of the same board. Unfortunately even education does not work, as it's not possible to track who did the last changes. Suggestion: Have users confirm that they would like to save the updated settings or allow a user to save some personal settings for a schedule board.

  • Organize Schedule Board tabs

    When users/administrators handle a significant number of schedule boards (this gets even worse when using RSO, because that adds boards per RSO scope) they are faced with a long row of tabs and need to scroll left and right to find the respective board. Suggestion: Introduce a 2-level hierachy or move the non-recently used boards to a dropdown selector.

  • Make "View Resource Card" popup configurable

    The resource cell is already configurable using HTML and CSS. However due to its limited size (in particular with many resources and a small row height) it would be great to be able to also configure the resource card popup.

  • Allow custom actions on Booking right-click

    In almost every implementation, custom actions to a booking become necessary. Having to open the booking and calling logic by clicking a button or running an ondemand workflow is quite cumbersome for a dispatcher. Suggestion: To achieve maximum flexibility, provide the ability to register custom workflow actions per entity type.

  • Allow updating booking details from the details pane

    To change booking details (other than start/end and resource), a user needs to open the booking form (e.g. to change the lock option). Suggestion: The details pane already allows the selection of custom views to only show the necessary fields. Can we make this view editable?

  • Show calendar week even in hourly boards

    Lots of customers plan based on calendar weeks. Suggestion: Show calendar week even in hourly boards. Ideally allow a less granular hourly board, so that a scheduler can see 2 weeks without scrolling. Calendar weeks might be different per region (e.g. US vs. Europe).

  • Web resource should be able to access current schedule board context

    Currently it's possible to add a custom web resource to a schedule board. It would be helpful if 1) the web resource could access the current context, i.e. displayed date range, selected resource, selected booking etc. to show the respective details. 2) an update of the SB context would also a refresh of the web resource. This would be similar to the current behavior of the details pane.

  • Allow different types of work hours, such as normal, overtime, travel-only, etc.

    We often get requirements where bookings should not be stricly constrained by the working hours. For an emergency, it may be acceptable that the technician works longer. Or travel from/to the job might be possible or even required outside the working hours. It would be great if we could define different types of working hours ourselves. Example: "Working Hours" from 8am to 5pm, travel and work allowed. 7am to 8am "Travel Hours" only for travel, not for work. 5pm to 7pm "Extended Working Hours", available for travel and work, but at a higher cost. Ideally this would also be taken into consideration by RSO, which of course adds a lot of complexity.

  • Allow resources to travel before work hours start or after they end

    Especially in urban areas, there is often the requirement to start the first job with the beginning of the work hours. The resource is responsible for traveling there outside working hours. The same at the end of the day. We could define this at resource level, so that the first job of the day would not cause travel. Probably acceptable for the dispatcher and Schedule Assistant, however for RSO this would probably mean that RSO would schedule the most remote job first to save on overall travel time, and then the resource needs to travel hours to reach the job. We could either define a period (max. 1 hour personal travel) or extend the entire work hour model. Separate idea posted here: https://experience.dynamics.com/ideas/idea/?ideaid=05ae9c1c-1644-e911-867a-0003ff68861e