SHOW ALL CONTENT

Advanced search

Introduction

Site management is an important part of the daily usage of Octopus. Sites are used in requests, in user files, in CI files; in other words, they are omnipresent and critical to Octopus.

In this article, we explain the different fields and terms used to represent each level of a site and how this information is found throughout the application.

Basic Configuration

The basic configuration is completed from Reference Data Management through several tabs. Site configuration is found under the section General > Sites.

Visual Explanation

General Information tab

Abbreviation: A shorter name to identify sites. Can also be used in columns.
Address: Physical address of a site. Can also be used in columns.
Time Zone: Allows assigning a time zone different from the default one. See the article on Time Zones for additional information.
Service Desk: When a specific group or service desk must receive all requests for a specific site, it can be specified from this option. For example, the Service Desk (group) IT-CA is responsible for all requests from Canada. It is then possible to specify in the site file the direct Service Desk (group) taking this site in charge.
Merge: Just as found in other sections of Octopus, the Merge feature allows replacing a data by another, throughout the application. In a case where two sites are merging together, the first one selected will be deleted (including in History tabs) and will be replaced by the second one.

NOTE: Due to the impact of such database manipulation, a site merger should only take place outside working hours to avoid a risk of slowing down on the Octopus environment.

Note: Allows to add a note to a site that can be used in lists and as search criteria.
Active Directory OU associated with this site: Allows automatically linking all data coming from an OU (Organizational Unit) of Active Directory to an Octopus site. Several OUs can be entered in this section, one OU per line. The Browse Active Directory icon right beside the box allows navigating the network to get the exact OU names (as required by Octopus) without having to enter them manually.

NOTE: The long Windows OU name is required in this section. It is suggested to use the Browse Active Directory icon to facilitate entering all OU names in the right format.

Available Requests tab

This tab allows limiting available request types to sites and subsites to make the selection site specific.

The choices are:

Allow all SR types and incident templates: Makes all types and templates available for this site. This is the choice by default when adding a site.
Allow SR types and incident templates selected below: Limits the availability of SR types and incident templates for this site to the selected ones.

To find out more on site restriction, see the How does Octopus handle site restriction? section of this article.

SLA tab

SLA tab allows to specify service level agreements based on the site.

Just like the Available Requests tab, the choices are:

Use global SLAs (defined in the Options form): Applies default SLA, as defined in Reference Data Management or in Options (both available from the Tools menu).
Use custom SLAs defined below: Limits the site to specific SLAs entered in this window. Does not rely on default SLAs.

NOTE: Specifying site-specific SLAs is only available at the higher level of a site (root site). Sub-sites do not allow this configuration. It is important to take this into consideration when deciding the number of site levels desired when building the Octopus configuration.

Explanation and advanced configuration

Real site levels

When configuring Octopus, we have to frequently specify several site levels to document for example, countries, provinces, cities, buildings and even floors and other physical locations, based on customer needs.

Here are the different logical levels of available of sites in Octopus:

Root site: Represents the first level from which the leveling starts. It is the highest possible level.
Parent site: Represents the superior level of a specified site, without necessarily being its root site. It is the highest level, from a structural point of view.
Sub-site: Represents the sub-site of a specified site. It is the lowest level, from a structural point of view.
Site: Represents the overall sites of an element (CI, user, request, etc.), including all levels, like root, parents and sub-sites.

Contextualization

Consider the context in which the sites and sub-sites represent the country, province and the cities within that province. The client operates across Canada and the United States, and must manage its users according to their exact location.

In this exact case, one of the main sites (root) is Canada, followed by a sub-site (second level of sites) which is the province of Québec, which then contains several sub-sites that are cities (third level of sites) like Montréal, Sherbrooke, Rimouski, etc.

Canada -> Québec -> Montréal, Sherbrooke or Rimouski

Based on the logic established in the previous section, a user belonging to the Montréal site level would have these values:

Root site: Canada
Sub-sites: Québec, Montréal
Parent site: Canada, Québec

As we can see, values in Sub-sites or in Parent site are all corresponding values and not only its adjacent level.

Visual explanation

Columns and major search fields

When using site columns in Octopus, here are the 4 corresponding columns to retrieve sites information:

To display a column showing only the root site (Canada, in this case):
- Add the column Root site.
To display a column showing the parent sites (Canada, Québec, in this case):
- Add the column Parent site.
To display a column showing the actual site and sub-sites over it, excluding the root site (Québec, Montréal, in this case):
- Add the column Sub-sites.
To display all site levels, including root and all sub-sites (Canada, Québec, Montréal, in this case):
- Add the column Site.

What you need to know:

Adding the Full Name field will display the same information as the Site field. This is simply another option to retrieve information, depending on the most evocative field name and customer context.

Additional site information fields

Take note that it is also possible to retrieve additional information linked to sites, found in Reference Data Management.

To display the site abbreviation:
- Add the field Abbreviation.
To display the physical address of a site:
- Add the field Address.
To display only the last level of a site in which the item is located:
- Add the field Name.

What you need to know:

Take note that even if the information in this Wiki is written based on columns, the logic stays the same if you desire to find the information through advanced search.

How does Octopus handle site restriction?

Octopus allows restricting the type of request that can be submitted by users according to the site writen in their file. This restriction applies both to the software and on the Web Portal, but it has specific rules.

To find out how to configure restrictions by site, see the Restrict a request by site section of the Restric a template article.

We will use scenarios in the sections that come to illustrate these rules.

Request created directly in Octopus by an Octopus user (tech)

When creating the request, the Octopus user chooses the name of the requester and the name of the user, if the latter is different from the requester. By default, the site chosen in Octopus will be that of the user, but this site can be modified by the Octopus user.

As the restriction is based on the site of the request, the templates of incidents and types of SR presented to the Octopus user will be those authorized for the chosen site.

Note : If the site restriction is applied, we recommend that the site should be mandatory in the options.

Go behind the scene to understand

A restricted request for "Indoor parking request" exist for the Montreal site only.
Carl Bernier is associated with the Montréal site.
Vicky Dumont is associated with the Toronto site.

When Carl or Vicky make a request to the Service Desk, the available requests will differ depending on the situation:

Carl makes a request:

For himself, by default, the request is available, since he is from Montreal.
For Vicky, the request will not be available by default since she is from Toronto, but the Octopus user can change the site of the request to access it.*

Vicky makes a request:

For herself; the request will not be available by default, since she is from Toronto, but the Octopus user can change the site of the request to access it.*
For Carl; by default, the request is available, since he is from Montreal.

* WARNING:
When there is a site restriction, it is necessary for the Octopus user to ask more information before submitting the request, as there is a reason for the site restriction.

Request created on the Web Portal by the requester

When a person accesses the Web portal and makes a request, that person will be by default the requester. However, certain types of request allow to choose a user different from oneself.

If the site is mandatory in the options, it will be visible when the person creates a new request. If the site is not mandatory, it will be based on the site of the user of the request and can not be modified on the portal.

As the restriction is based on the site of the request, the incident templates and SR types presented to the Octopus user will be those allowed for the user's site.

Go behind the scene to understand

A restricted request for "Indoor parking request" exist for the Montreal site only.
Carl Bernier is associated with the Montréal site.
Vicky Dumont is associated with the Toronto site.
We remind you that when the site is mandatory in the options, it will be visible on the Web Portal when creating the request, otherwise the site cannot be modified.

We will see the most frenquent cases when Carl or Vicky make a request on the Web Portal, the available requests will differ depending on the situation:

Carl makes a request for himself, whether the site is visible or not, the request is available because he is associated with the Montréal site.
Vicky makes a request for herself, if the site is visible, she can choose the Montréal site, select the request type and fill out the form.
- If the site is not visible, she cannot proceed.

For other, more complexe, cases see the Specific cases of requests restricted by site FAQ.

Recommendations when using the site restriction

The site restriction is subtle and people do not always know the rules behind the behaviour of Octopus. The first recommendation is to make the site mandatory in the options.

Then we recommend adding a message in the form for those who will complete the request on the Web Portal explaining the restriction of the request and the reasons.

For Octopus users, a procedure may help them better understand when a restricted request per site is permitted or not.