Thank you for your feedback.
Form temporarily unavailable. Please try again or contact docfeedback@servicenow.com to submit your comments.
Versions
  • London
  • Kingston
  • Jakarta
  • Istanbul
  • Helsinki
  • Geneva
  • Store
Close

Resource allocation

Resource allocation

After resource requesters create a resource plan, resource managers allocate resources to the plan and set it to the Allocated state.

Based on calendar and schedule information, resource managers view resource availability and select the resources under their management that can be allocated to specific tasks.

Booking type

When a resource plan is created, it defaults to the Planning state and default allocations are created automatically. These allocations have a Booking type that is Soft. Soft allocations are like a temporary placeholder allocation for the requested users. Soft allocations do not create calendar events. When a resource plan moves to the requested state, the allocations are still soft. When you set the plan to the allocated state, the Booking type changes from Soft to Hard, meaning that the resource is unavailable for another booking and the booked time is reflected on the user's calendar.

The Requested hours field specifies the number of hours requested per allocation record.
Note: The Booking type of the allocation record will remain Soft if the requested resource cannot be allocated for the whole of the allocation duration.

Requested hours calculation

Requested hours are calculated as follows when the Allocations value is set to Plan Duration:
  • For a single user resource, one allocation is created for entire duration with planned hours as requested hours. For example, if a user is requested for 9 planned hours, the Requested hours value is also 9.
    User Allocation start Allocation end Requested hours
    User name Planned start date Planned end date 9
  • For a group resource, the hours are split evenly across all members irrespective of their availability. The minimum unit for the allocation is 1 hour. Any residual hours are assigned to users one by one until there are no more hours.
    For example, the requested hours for a two-member group are allocated as follows:
    User Allocation start Allocation end Iteration 1 Iteration 2 Requested hours
    Member 1 Planned start date Planned end date 4 1 5
    Member 2 Planned start date Planned end date 4 4
Requested hours are calculated as follows when the Allocations value is set to Weekly/Monthly:
  • For a single user resource, the application calculates the working days for each week or month from the user's schedule. The following calculation is used: hours per week/month = (planned hours * working dates in the week/month)/total working days.
    These two examples show how requested hours for a user is calculated:
    Period/Working days Requested Hours
    Week 1 / 5 days 20
    Week 2 / 5 days 20
    Total 40
    Period/Working days Calculation (iteration 1) Calculation (iteration 2) Requested hours
    Week 1 / 4 days 4 * 4.44 = 17.76 (rounded to 17) 1 18
    Week 2 / 5 days 5 * 4.44 = 22.22 (rounded to 22) 22
    Total 39 40
  • For a group resource, the working days are calculated for every user for each week or month from the users schedule, and for the group for each week or month. The following calculations are used:
    • group hours per period = (planned hours * group working days in period)/total working days
    • user hours per period = (group hours per period * user working days in period)/group working days for period
For example, a two-user group is calculated as follows:
Users in the group Week 1 Week 2
Working days Requested hours Working days Requested hours
User 1 4 9 4 9
User 2 5 11 5 11
Total 9 20 9 20

Allocation examples

When hard allocations and their corresponding calendar events are created, hours are spread evenly across the allocation duration, starting with the Geneva release. For example:
  • 4 hours for 1 week, with an allocation interval of 60 minutes: creates a 60 minute block from Monday through Thursday.
  • 4 hours for 1 week, with an allocation interval of 30 minutes: creates a 60 minute block from Monday through Wednesday and 30 minutes blocks for Thursday and Friday.
Note: You can control the minimum unit for an event by modifying the Calendar Event Duration (Minutes) (com.snc.resource_management.allocation_interval_minutes property). The default is 60 minutes.

Over-allocation

Over-allocated resources is allowed, starting with the Geneva release. Over-allocating resources creates overlapping events in the user calendar within the user's scheduled hours. However, a maximum of 24 total hours can be allocated in any given day. Overlapping events appear overlapped in the calendar in the weekly view. In the monthly view, overlapping events appear as above or below another.

For example, a user has a schedule that specifies the work day from 08:00 to 17:00 daily. Event 1 is in the user's calendar from 08:00 to 14:00. If an additional 5 hour are added for the same day for Event 2, an event is created for the 3 hours of free time (14:00 to 17:00) and an overlapping event is created for the remaining 2 hours starting at the beginning of the day (08:00 to 10:00).

Figure 1. The overlapping event from the monthly view
Figure 2. The overlapping event from the weekly view