Using sites for remote users

In xMatters, sites represent physical locations like street addresses or geographic coordinates. For example, sites could include: “Vancouver”, “Building C”, or “37.7728044, -121.95957570000002”.

When you configure a site, you need to specify its language, time zone, and country. These then become the default values assigned to any user added to that site. A user’s site also determines their dialing codes and toll-free numbers, and potentially their on-call availability if the site has custom holidays and gets associated with their groups.

And, if you optionally provide an address or coordinate for your sites, you’ll be able to see them on a map and target users for notification based on their geographic location.

What if users don't have a site?

What should you do if there are users in your organization that aren’t associated with a physical location because they work remotely? What value should you assign as their site?

Well, that depends. A few things to think about are:

Do you only really need to distinguish between on-site and remote users?

• If you simply want to be able to differentiate between on-site and remote users (for example, a central, head office that coordinates field agents), then you could assign all remote users to a single location – like the default site or a “remote” site.

Do you want to be able to contact users based on their geographic location?

• If you’ll want to notify users based on their geocoded location (i.e., all users within the path of a severe storm), then you'll need to create a site for each remote user, or group remote users into sites that represent different regions.

Do your remote users require different site holidays or a variety of time zones?

• If your remote users are geographically distributed, they may have different holidays and time zones, so you may want to create multiple remote sites with different custom holidays.

With these points in mind, this article breaks down different options for assigning your remote users to sites. There may be other approaches - or hybrids of these options – that may also work for your organization’s needs.

Option 1: Assign remote users to the default site

The first approach, which distinguishes your remote users from the rest of your on-site users, is to simply assign remote users to your company’s default site. If you’ve already created sites for all your physical office locations and assigned your on-site users to them, then the default site may be a quick and easy option.

A drawback of using the default site for remote users is the potential risk of accidentally classifying new on-site users as remote if you add them to your company and don’t select a site (they’ll get added to the default site by, well, default).

Option 2: Create one or more designated “Remote” sites

Another way to avoid potentially mixing up your remote and on-site users is to create a “Remote” or “Remote Users” site specifically for your remote users.

If your remote users are geographically dispersed, with different holidays and time zones, you can create more than one remote site – for example, “Remote – California” and “Remote – Florida” sites.

Option 3: Create regional remote sites

If you’ll want to notify remote users based on their geographic location, you may want to organize users into geocoded sites that represent different regions. Regions could be things like municipalities, cities, states, zip codes – or any other type of region that makes sense for you.

Like Option 2, you will want to assign a physical location to your sites. Only sites with an assigned location are available in the site recipients section of the form layout, which lets you notify users based on the site they belong to.

For example, you could create sites located in the center of zip code areas (or states or cities) and assign users to them based on their address information.

Option 4: Create a site for each remote user

If you require more granular control over locations, then you may consider creating a site for each remote user. Depending on how many remote users you have – and whether you need to add them all at once or gradually over time – this could be a big task.

The good news is that that xMatters has some internal tools that we can use to help upload and geocode sites in bulk. Contact xMatters Customer Support for more information about the xMatters Toolbox.

Some other important notes:

• The time zone and language settings you configure for a site apply to the users assigned to it, but your users can modify these settings from their user profile in the web user interface. (You can also specify the time zone and language for individual users during the import process.)
• Users that can't update their time zone and language settings themselves may require a supervisor or administrator’s assistance. This can occur if these fields are locked because they’re managed in an external system, or if a user is unable to access their profile in the web user interface (such as mobile-only clients).
• To select a site using the site recipient section of the form layout, you’ll need to assign location information to your site.
• Another way to select users based on their site is with dynamic teams. Dynamic teams are created based on custom fields – such as a site or location – and are automatically populated to include members that match specified criteria. You can also add dynamic teams to groups and include them in on-call schedules.

xMatters internal reference: DOC-8194