We established a gap in Field Service after a discussion in the Field Service Yammer Group in regards to Multiple Resources and the Resource Requirements. If you for example would like to schedule a Work Order to 2 Resources, you will find that this can't easily be done without any customization or even coding (plugins / custom workflow activities) in the system. Although you theoretically can schedule the same Resource Requirement twice, you would most likely want the Resource Requirement to disappear from the "Unscheduled Work Orders" view (or custom view for that matter) in the Schedule Board once it has been planned. The Resource Requirement does have a Quantity Attribute which is described in the MSDN as "Enter the number of resources required.". This attribute however does not seem to be used anywhere. So as a partner we have a few options, which I would love to see natively available in Field Service. 1. Multiple Resource Requirements One way to resolve this natively in Field Service, would be by introducing a new setting in the Administration page of Field Service "Create individual Resource Requirements". In the background, Field Service can then create duplications of the Resource Requirement based on the Quantity of the original/parent Resource Requirement. These can then be individually filtered and planned. 2. "Remaining Quantity" Another approach is a new field on the Resource Requirement named "Remaining Quantity". The Resource Requirement would be generated / created with a "Quantity" of 2. The "Remaining Quantity" is then automatically set to the same value upon creation. Every booking will result in the "Remaining Quantity" to be reduced by 1, where as a cancellation or deletion of the booking will result in the "Remaining Quantity" to be increased by 1. Therefore enabling you to filter the Resource Requirement properly. In addition to that, it would be nice to see a way to define the "Quantity". Possibly on the Incident Type. I feel having both options in Field Service available, will enable the architect/lead to decide the best approach for their case. Resources Groups do not fulfill this gap, as that would be the preferred approach if the customer has fixed teams. As an example: you might be inclined to use a single Resource Requirement with multiple bookings when the Resources work together during an installation on the same date and time, while you might want multiple Resource Requirements when using different date and times so you can configure the "Promised time / date" fields accordingly.