Setup and configuration

Completed

Before an organization can schedule items with Universal Resource Scheduling (URS), there are several components that you need to configure first to ensure that you can schedule items effectively based on the organization needs.

Organizations should consider items such as the following:

  • What type of items are we scheduling?

    • Can resources be scheduled for multiple items in a single day (break fix, appointments, etc.), or do they tend to only work on one item for multiple days at a time (projects)?
  • What does an unscheduled item look like?

    • Can there be multiple statuses for an unscheduled item?
  • What does a scheduled item look like?

    • Is there a difference between just being scheduled and working on it?

    • What about items like breaks and travel time? How does that affect booking statuses?

  • Are you using GPS information?

    • Where are resources dispatched from? (A central office, their home, it depends)
  • What factors can affect scheduling of a resource?

    • Location? Skills or Certifications?

While this list is by no means complete, it does help in identifying the types of items that you need to consider. It helps you to ensure that when you configure URS settings, you consider everything that could affect how items are scheduled.

Where to begin

The first thing you want to configure before you do anything else in URS is its mapping functionality. By default, URS doesn't connect to any specific mapping provider. You can modify it by going to Settings > Administration > Scheduling Parameters. From scheduling parameters, you can control items like how often the schedule board refreshes (default 30 seconds), and the unit and radius that are used by the schedule assistant when offering recommendations. For example, setting the default radius unit to miles and the default radius value to 20 would mean that when resources are suggested, only qualified resources within a 20-mile radius will be suggested. You want to take some time and consider what is needed here to ensure optimal success when configuring other components.

By default, the connect to maps field is set to No. You need to set it to Yes to ensure that the schedule board and schedule assistant use maps to schedule items. By default, it uses Bing maps, but you can configure it to work with any mapping provider. Provide a specific Map API Key value for the mapping provider you want to use in the Map API Key field. Additionally, organizations can configure a custom-mapping entity to populate items like longitude and latitude if needed.

Screenshot of the Connect to maps feature noted as yes.

Organizational units

Organizational Units are used to group different resources together in containers. Organizational units could be used when you have resources that are all located in a specific location. For example, a software company might have resources that are in France, the United States, and Germany. An Organizational Unit could be created for each of these locations where resources are stored. This model is typically used when URS is going to be applied for more project-based scheduling.

Another option where Organizational Units are often used, is as locations that resources might be dispatched out of. For example, an organization might have offices in Seattle, Tacoma, and Portland. Organization Units could be created for each of those locations. When an Organizational Unit is going to be used to define a dispatching location, it needs to have valid Latitude and Longitude settings defined. You can specify these settings on the Scheduling tab of the Organization Unit.

Screenshot of the Organizational Unit latitude and longitude settings.

Note

The organizational unit entity is not geo-coded like other entities. You will need to use a mapping provider (ex. Bing) to find the physical location address and copy the latitude and longitude information to the organizational unit.

Resource skills, roles, and proficiency models

Some items that are going to be scheduled might require the resource to have a certain role or that they possess a specific skill or certification to work on it. For example, to perform a security system installation on a specific brand of security camera, the person being scheduled must be a certified installer and be highly skilled at installing that specific brand of security camera. To help in these scenarios, URS lets organizations define these options in the application:

  • Roles: Specifies a specific role(s) in an organization that can be associated with different resources. Roles can be added to specific resources and schedulable items like a work order to ensure that only resources with that role are suggested as people to work on an item.

    • Examples of common resource roles include Developer, Solution Architect, technician, and functional consultant.

    • A single resource can have multiple roles assigned to them. For example, a resource can have a developer and technician role assigned to them.

  • Skills: They specify a specific skill or certification that can be associated with different resources. They're also referred to as characteristics in Field Service. Each characteristic needs to have a Characteristic Type defined. There are two options available:

    • Skill:

    • Certification:

      You can also use Resource Skills to support specific scenarios where resources need specific access to something, like a building, or need a specific level of security clearance.

      Examples of Resource Skills include:

      • A certification like A+, MSCE, etc.

      • A skill set like C#, Azure, Exchange, etc.

      • Access or security clearance like Building 12 access, or level 1 security clearance.

      It's likely that a single resource might have multiple skills assigned to them.

  • Proficiency Models: Are used with resource skills to define how proficient someone is on an item. Proficiency models can be used to define different types of scenarios.

    Product Proficiency Security Clearance
    Familiar Level 1 Clearance
    Good Level 2 Clearance
    Skilled Level 3 Clearance
    Highly Skilled Level 4 Clearance
    Master Level 4 Clearance

Booking statuses

Booking statuses are used to communicate the status of a booking. Organizations can create specific statuses to reflect their specific needs. For example, after an item is scheduled it can fall into one of these statuses:

  • Scheduled

  • Traveling

  • In Progress

  • Completed

We can define each of these statuses in the application, additionally organizations can associate each status with a specific color, and image. The color and Image would then be displayed on the schedule board for any item that is currently in that status.

You should consider which types of items you want to use the schedule board for and which statuses those items could be in. You can create several different booking statuses to reflect those items. For example, if you wanted to display time off on the calendar, you would want to create booking statuses for common time off items like vacation, business events, or personal time. This practice ensures that everything that needs to be shown is populating as intended.

Screenshot of the Legend for booking statuses displayed on the calendar board.

Requirement statuses

Requirement statuses are like booking statuses, but they're associated with the scheduling requirement. Typically, you don't need as many requirement statuses because they don't have the same lifecycle. A common example of requirement statuses might include:

  • Active: A requirement that wasn't yet scheduled in the system

  • Completed: a requirement that was successfully scheduled and has a related booking created.

  • Canceled: A requirement that no longer needs to be scheduled for some reason.

Other considerations

Since every organization is unique, and might have their specific scheduling needs, there are other items that can potentially be configured as needed. These Items include:

  • Resource Groups: Used to group together multiple resources that can be used to work on items.

  • Resource Group Templates: Used to create templates that can be used to quickly create and deploy resource groups that are most used.

  • Fulfillment Preferences: Help to specify how items can be scheduled. For example, a fulfilled preference might define that when attempting to schedule an item:

    • It should use intervals of 60 minutes.

    • They should be scheduled at the top of every hour.

  • Work Hour Templates: Used to create templates that can be assigned to resources to define the hours that they're available to be scheduled for to work on items. For example, let's say that you have multiple technicians in a specific time zone that work from 8:00 AM to 5:00 PM. A work hour template can be created and associated with each of those resources.

  • Priorities: Used to note the priority of the requirement. Priorities can be taken into consideration to ensure that items with higher priorities are scheduled with items that are considered lower priorities.

  • Business Closures: Specifies when an organization isn't open such as holidays.